Re: Sites using webkitAudioContext only

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.

The first set of problems have been discussed extensively here.  The second
set of problems are very important to address in my opinion, especially
given the fact that the rest of the web platform has been designed with
data races in mind.  The third category is important to address for
performance reasons.  The fourth category will make it more natural to
write code using Web Audio that looks and acts more similarly to other
parts of the web platform.

These are all going to be difficult to address once an implementation ships
an unprefixed implementation.  I would be more than happy to discuss the
last three categories in their own threads (and also suggest strawman
proposals for each one of them) but before doing so I'd like to know if
Chris Rogers is open to the general idea of fixing these kinds of problems,
given that we really need Blink to be on board with adopting these
changes.  As I've stated before several times, the fact that Chris Rogers
has not been on board so far has forced us in Gecko land to implement the
API as is, and also for us to advocate spec'ing things like the alternate
names explicitly and not as suggestions.


>
> Mozilla needs to ship something soon; we're hoping to ship in a release in
>> about 14 weeks. If we ship only the new names then a lot of existing
>> content won't work, even content that authors expect should work since they
>> used AudioContext || webkitAudioContext, or similar. People will complain
>> that our implementation is broken and get the impression Web Audio doesn't
>> work properly in Firefox. That is very damaging and takes a long time to
>> recover from.
>>
>
> If you ship only the new names, a lot of existing content won't work.  If
> you ship the old names, but not webkitAudioContext, still a lot of existing
> content won't work.  That content was developed to a prefixed, potentially
> non-standard implementation, by definition.  Unless your goal is to exactly
> replicate the webkit-prefixed platform that content was written on, it's
> not all going to work.  We need to be realistic - today, there is no
> shipping implementation that even uses the correct unprefixed name, so
> anyone who writes var ctx = AudioContext is just being hopeful.  I believe
> we (me, in particular) owe a responsibility to get that content migrating
> to the proper, standards-specified implementation, and I CERTAINLY am
> responsible for getting the guidance on HTML5Rocks to show proper usage,
> but we have not been able to start that yet - but we need to be realistic
> that on day one, all the content developed to the nascent webkit/blink
> implementation is not going to work on a standards implementation, and some
> of it never will (if it's never maintained).
>

I agree that expecting things to work seamlessly on day one is
unrealistic.  But this is not a problem that gets easier to solve as time
passes, and at least I'd like to see if there is a desire to address them.
As I've said before I'm ready to make Gecko changes depending on whatever
we end up deciding here, even if that means delaying shipping Web Audio in
Firefox for one release, but as Robert mentions, we're also working hard
against deadlines, and we can't wait indefinitely, so at some point we're
going to make the sad choice of shipping what's currently spec'ed...


>
>
>> So, I'm adamant that whatever we ship needs to be compatible with where
>> Chrome is going to be in 3 months, at least for authors who've done
>> AudioContext || webkItAudioContext. So if Google can't commit to removing
>> the old names from AudioContext in a Chrome release by then, I think we
>> need to keep them. (Retaining them in webkitAudioContext may be OK.)
>>
>
> So, I think around the time Mozilla releases (or at least, not too long
> thereafter), I'd like for Chrome to release unprefixed as well.  I'd like
> that unprefixed implementation to follow the specification, and to not have
> the old property names in that unprefixed implementation.  However, I don't
> believe in three months we will have removed the old property names from
> webkitAudioContext, nor removed webkitAudioContext altogether - that will
> take longer.
>

I think it's fine if webkitAudioContext remains unchanged for a reasonable
period of time.  However, if we're talking about retaining the current API
in webkitAudioContext for an extended period of time, then that defeats the
purpose here, as I believe that the final "incentive" for people to move
over their code to the standard API is for webkitAudioContext to stop
working, so having both the prefixed and unprefixed versions around for a
long period of time will make it really difficult for Chrome to remove
webkitAudioContext, and will hurt our efforts to end up with a good API
here.


> This overlap may cause some compatibility issues;  however, I'd point out
> that even shipping an unprefixed clean implementation alongside
> webkitAudioContext is going to break a fair bit of content for us.  There's
> a subtle but important difference between
>     var ctx = AudioContext || webkitAudioContext;
> and
>     var ctx = webkitAudioContext || AudioContext;
>

I don't think that there's a lot that we can do for content written using
the first idiom...


> At the same time - BEFORE that time - I will edit the articles in
> HTML5Rocks to show proper guidance on prefixing, and use proper (new)
> naming for things like noteOn/noteOff.  In fact, it would probably be good
> to write an article that gives direct guidance on how to write content for
> the best compatibility and future-proof-ness.  I haven't gotten to that
> yet, but I will.
>

That's great, thanks!

--
Ehsan
<http://ehsanakhgari.org/>