Re: AudioBuffer mutability

On Wed, Oct 31, 2012 at 2:10 PM, Joseph Berkovitz <joe@noteflight.com>wrote:

> Some implementors may want to go the extra mile, in the way you suggest or
> some other way, and that would be laudable if it doesn't hurt performance
> too much. But I would be cautious about elevating this buffer-insulation
> policy to a hard requirement at this time, before we all understand the
> landscape better.
>
> I can't envision many of the things others will do with the API. And I
> sense from the questions you asked me that you might not have anticipated
> some of the legit reasons for reading and writing channel data. I suppose I
> am saying that overprotecting users, like underprotecting them, can also be
> bad for an API's evolution, and can make some very useful things impossible
> in an unintended way.
>

It's easy to evolve an API to be more permissive. It's very difficult ---
on the Web, often practically impossible --- to evolve in the other
direction. Therefore it is often necessary to err on the side of
overprotection at first.

However, in this case nothing we've discussed here would make anything
"impossible". No matter what choices we make here, Web authors would be
able to do whatever they want by keeping around an extra copy of the
buffer, and that is only a performance issue.

Rob
-- 
Jesus called them together and said, “You know that the rulers of the
Gentiles lord it over them, and their high officials exercise authority
over them. Not so with you. Instead, whoever wants to become great among
you must be your servant, and whoever wants to be first must be your
slave — just
as the Son of Man did not come to be served, but to serve, and to give his
life as a ransom for many.” [Matthew 20:25-28]