Re: Web Audio API spec review

On 05/16/2012 02:45 AM, Chris Rogers wrote:
>
>
> On Tue, May 15, 2012 at 4:15 PM, Robert O'Callahan <robert@ocallahan.org <mailto:robert@ocallahan.org>> wrote:
>
>     On Wed, May 16, 2012 at 10:33 AM, Olli Pettay <Olli.Pettay@helsinki.fi <mailto: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.
The spec is just a WD.

>  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,
Of course there is tremendous amount interest when you expose new functionality to the Web.


> 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).
I hope it wouldn't break developers ;)

But the API is going to be there for a long time. We really need to get basic things like thread handling and synchronization working correctly.
Otherwise we may end up to similar problems where we're with syncXHR and MutationEvents, where we're slowly trying to kill
very commonly used APIs. It is not fun to break sites because of changes to XHR handling - but we do that.
And we haven't even started to try to kill MutationEvents, we just have the replacement API ready.


I wish WebAudio API could be a layer on top of MSP. I could imagine other similar layers.
Something for video processing, perhaps for MIDI too.


-Olli


>  Changes which are simple stylistic preferences, or are gratuitous are very much less desirable to change at this time.
> Chris
>

Received on Wednesday, 16 May 2012 07:25:26 UTC