Re: Web Audio API spec review

On Tue, May 15, 2012 at 4:15 PM, Robert O'Callahan <robert@ocallahan.org>wrote:

> On Wed, May 16, 2012 at 10:33 AM, Olli Pettay <Olli.Pettay@helsinki.fi>wrote:
>
>> On 05/16/2012 01:26 AM, Robert O'Callahan wrote:
>>
>>> One thing that is going to be really important when addressing this
>>> feedback is understanding the existing compatibility constraints. As I said
>>> in an
>>> earlier email, if Webkit is unwilling to take a change, due to
>>> compatibility concerns, then we probably don't want to take that change in
>>> the spec either.
>>>
>>
>> What compatibility concerns? We're talking about an early draft of a
>> spec, which is even implemented prefixed.
>> Changing the spec sure should be possible.
>>
>
> Google has heavily evangelized use of Web Audio in production apps. It has
> been presented as *the* solution for audio processing, without caveats.
> Google people told me they're not willing to break compatibility with the
> content created under those assumptions.
>

Let me try to present this from a slightly different perspective.  This is
not an early draft of a spec.  It's a specification which has been
circulated, heavily discussed, and iterated on the W3C audio group
(initially the incubator group) for approximately two years.  Even before
that time the specification underwent internal API reviews at Google and
was presented to Apple, who provided considerable feedback.  There has been
a tremendous amount of developer interest, experience building applications
with the API, and feedback during this whole period, and it has been in
developers hands in shipping versions of Chrome for over a year, and more
recently in Safari builds.

That said.  To the extent that an API is clearly broken (by
consensus), then of course we will fix/change these things.  Similarly,
if something is implemented in WebKit which is a bug, not matching what the
specification would indicate and intend, then we will need to fix those
bugs in WebKit (even if it breaks developers).  Changes which are simple
stylistic preferences, or are gratuitous are very much less desirable to
change at this time.

Chris