Re: Question on Jer's proposal

On Jul 29, 2013, at 2:07 PM, Joseph Berkovitz <joe@noteflight.com> wrote:

>> I’ve updated the gist <https://gist.github.com/jernoble/6034137> to remove all references to “alternatives” and added a section about memory and performance considerations.
> 
> Thanks Jer.
> 
> Followon question: is every aspect of your proposal required for it to work?

Only so much as the required parts are required. ;-)

I’m certain that there’s a number of non-zero subsets of the proposal which would suffice.  E.g., I believe you could define a subset which would result in an immutable AudioBuffer, would you be so inclined.

> In particular it seems as though the audio-specific Float32Array set(AudioBufferChannel…) method is optional, given the existence of AudioBufferChannel.slice() -- you pretty much say this already in your proposal. I know some folks on the list expressed concerns about any Typed Array API changes since the WG doesn't control those specs. I don't have a feel for how extensions to some API w/r/t a type in another API are viewed in terms of ownership.

I asked around here a bit before adding that particular extension, and the advice I got was that this type of extension was relatively common.  (Specifically, I was advised to grep the W3C specs for ‘partial interface’ to see exactly how common.)

You are correct in that Float32Array.set(AudioBufferChannel) is not strictly required, so long as AudioBufferChannel.slice() exists.  However, it’s highly desirable to allow page authors to separate “copy” from “allocate-then-copy” semantics.

-Jer