Re: Sites using webkitAudioContext only

I'm a little confused on a detail here, so pardon my request for
clarification:

It seems like at present, we have effectively 'two different Web Audio
APIs':

AudioContext (and, to a degree, mozAudioContext), which are both
theoretically implementations that attempt to conform to the
spec-as-published
webkitAudioContext, which conforms to an older version of the spec and is
constrained by unfortunate backwards-compatibility requirements with
existing applications

And then as I understand things, it is very difficult to remove
webkitAudioContext from Webkit (to force use of the non-prefixed name) or
make backwards-compatibility breaking changes, because of existing web
content out there? This is also what's motivating discussions about Gecko
possibly implementing the prefix, right?

Assuming what I stated above is correct:

Would it be possible to do a 'least possible damage' sort of thing like MS
tried to when they globally disabled plugins (like flash), where we
whitelist known sites that need backwards compat and for whatever reason
can't be updated? This would keep existing big names like Angry Birds or
Turbulenz working in Chrome just like before, while limiting the spread of
broken/old Web Audio to new sites - people would use the broken code and it
wouldn't work (perhaps they'd even get an informative error in the console
telling them why) Whitelisting production domains only would also ensure
that anyone actively doing development against Web Audio would see these
problems in their development environment (since it's not whitelisted).
Even better, the whitelisting could function by loading a user script that
defines webkitAudioContext in terms of spec-compliant AudioContext, and
Firefox and other browsers could load that same user script to become
compatible with busted old content on the whitelist.

Is the difficulty of making changes to Webkit what creates the friction
here when discussing the possibility of bigger changes (like the
constructor pattern)? Or is it more that there is simply a desire to
solidify the current spec and ship it instead of continuing to iterate?

-kg


On Wed, Jun 19, 2013 at 2:26 AM, Marcus Geelnard <mage@opera.com> wrote:

> **
> Den 2013-06- 22:33:38 skrev Ehsan Akhgari <ehsan.akhgari@gmail.com>:
>
>
>
> On Sat, Jun 15, 2013 at 12:45 PM, Chris Wilson <cwilso@google.com> wrote:
>
>> On Fri, Jun 14, 2013 at 4:17 PM, Robert O'Callahan <robert@ocallahan.org>wrote:
>>
>> On Sat, Jun 15, 2013 at 9:45 AM, Chris Wilson <cwilso@google.com> wrote:
>>>
>>>> We are open to removing the old names from Blink; however, I expect we
>>>> will begin by offering a clean unprefixed version, and work hard at
>>>> evangelizing to move developers over to that standards implementation; we
>>>> can then remove the prefixed version at some point in the future (after
>>>> doing console warnings, etc., to deprecate its usage).
>>>>
>>>
>>> The problem is that this all needs to be done very soon.
>>>
>>
>> Indeed, I can understand why this is time-critical for Mozilla, as you
>> need to make decisions before shipping.  That's why I'm even MORE concerned
>> about the introduction of the possibility of "more drastic changes",
>> because any even medium-sized changes (and definitely something as major as
>> changing the constructor pattern) is going to change this discussion.
>>
>
> Here are the three categories of things which I would like to see changed
> in the current spec:
>
> * Having more than one way to do things in the API.  This is mostly the
> question of the alternate names which we're currently discussing.
> * Ways in which the API design introduces data race possibilities.  This
> includes things such as allowing read-back from buffers used by the audio
> processing code, such as WaveShaperNode.buffer, AudioBuffer.getChannelData,
> etc. as previously discussed on the list.  Removing these read-back
> mechanisms would make it possible to use copy-on-write techniques in order
> to make sure that we avoid copies where we can, and that web content will
> not be allowed to do things which introduce data races.
> * APIs which make it possible to write inefficient code.  The synchronous
> decoding using AudioContext.createBuffer is the only one here that I can
> think of.
> * General Web API design best practices.  This includes things such as
> using constructors instead of creator methods, using DOM event targets
> (which we have already fixed), using DOM Promises for callbacks as opposed
> to plain functions, etc.
>
>
> Technically, that sounds like four categories ;-)
>
> I would like to add that there are still some pretty awkward interfaces in
> the API (might fall under the last category, or in a separate
> "consistency/clean up" category?). In particular, not much has happened to
> the AnalyserNode (except for changing names from RealtimeAnalyserNode):
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=17361
>
>
> --
> Marcus Geelnard
> Technical Lead, Mobile Infrastructure
> Opera Software
>