Re: Web Audio API spec review

Unless the W3C Recommended API is named "webkitAudioContext", this
shouldn't be too much of a problem.

Seriously, though - no, we do not want to arbitrarily break the games and
other apps that have gone out already using early versions of the Web Audio
API, but we are committed to migrating those apps over to a standard API
that works across browsers, whatever that API might be.  While I agree our
evangelism has not been quite perfect in terms of clearly delineating
experimental and early APIs, I would point out that in our more recent
efforts (e.g. recent articles on HTML5Rocks), we've been purposefully
improving that, and even with that admission, I would not characterize our
past efforts as heavy evangelism for production apps.  And it currently
*IS* the only solution for audio processing in Chrome; we certainly hope to
improve it and turn it into a cross-browser standard API, but we've never
presented it as such that I know of.

At any rate - we can absolutely take breaking changes - for some features,
even under our webkit prefix.  I don't know, to use one example, how
quickly we could remove "noteOn" after adding "start", under the webkit
prefix- I wouldn't want to break Angry Birds, etc., although I'm happy to
go evangelize that they need to change their code for such changes
(presuming there's an actual reason and it's not gratuitous).  After all,
that's my job.

As the standard stabilizes, I'd expect we would all implement unprefixed,
and it would reflect whatever is in the spec.  If late-breaking changes
come up, we would have to break people.

-Chris

On Tue, May 15, 2012 at 4:37 PM, Olli Pettay <Olli.Pettay@helsinki.fi>wrote:

> On 05/16/2012 02:15 AM, Robert O'Callahan wrote:
>
>  On Wed, May 16, 2012 at 10:33 AM, Olli Pettay <Olli.Pettay@helsinki.fi<mailto:
>> Olli.Pettay@helsinki.**fi <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.
>>
>
> That sounds like a bug in Google evangelism process. Or is it the case
> that they have evangelized for
> Chrome Web Apps (or whatever is the right term). Those are in a walled
> garden, so not really part of the web.
>
>
> -Olli
>
>
>
>  Google people told me they're not willing to break compatibility with the
>> content created under those assumptions.
>>
>> Rob
>> --
>> “You have heard that it was said, ‘Love your neighbor and hate your
>> enemy.’ But I tell you, love your enemies and pray for those who persecute
>> you,
>> that you may be children of your Father in heaven. ... If you love those
>> who love you, what reward will you get? Are not even the tax collectors
>> doing
>> that? And if you greet only your own people, what are you doing more than
>> others?" [Matthew 5:43-47]
>>
>>
>
>
>