Re: Web Audio API spec review

On 05/16/2012 10:24 AM, Olli Pettay wrote:
> 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.


Let me re-phrase this to a question.
Are there any technical reasons why an API very similar to WebAudioAPI couldn't be
built on top of an API very similar to MSP?



-Olli





>
>
> -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 09:43:30 UTC