W3C home > Mailing lists > Public > public-audio@w3.org > April to June 2012

Re: Web Audio API spec review

From: Chris Rogers <crogers@google.com>
Date: Wed, 16 May 2012 12:07:26 -0700
Message-ID: <CA+EzO0kYcdF7DTx82FzN=bixtEbR1EnE=up2C5gYemB_Le94wg@mail.gmail.com>
To: Marcus Geelnard <mage@opera.com>
Cc: olli@pettay.fi, Chris Wilson <cwilso@google.com>, robert@ocallahan.org, Philip Jägenstedt <philipj@opera.com>, public-audio@w3.org
On Wed, May 16, 2012 at 12:06 AM, Marcus Geelnard <mage@opera.com> wrote:

> Den 2012-05-16 01:54:17 skrev Chris Wilson <cwilso@google.com>:
>
>
>  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.
>>
>
> I don't really see this as an issue. We could have two audio API:s during
> a transitional period:
>
> * The WebKit prefixed version, which basically stays as it is today and
> continues to support legacy applications that are unlikely to migrate to
> the new API in a timely manner.
> * The un-prefixed cross-browser "standard" version.
>
> The fact is that whatever the audio API will look like, it will stay
> around for a very long time - and I think the Web deserves a good,
> sustainable audio API, so let's not push something just because of legacy
> support (there are already too many examples of that in the computer
> industry).
>
> /Marcus
>

Hi Marcus,

I'm not sure that this approach of supporting two versions in WebKit (the
prefixed and un-prefixed standard version) aligns with Robert's concern
about "overhang", where there might be some subset (perhaps large) which
will only work in WebKit browsers.

But, if you're talking only about a "transitional" period instead of
supporting two versions in WebKit forever, then maybe that could work.

Chris





>
>
>  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]
>>>>
>>>>
>>>>
>>>
>>>
>>>
>
> --
> Använder Operas banbrytande e-postklient: http://www.opera.com/mail/
>
Received on Wednesday, 16 May 2012 19:07:56 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 16 May 2012 19:07:58 GMT