Re: Sites using webkitAudioContext only

On Mon, Jun 17, 2013 at 1:33 PM, Ehsan Akhgari <ehsan.akhgari@gmail.com>wrote:

> 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.
>

Yup.


> * 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.
>

OK.  I've seen some discussion of this in the list, and I'll presume these
are filed issues.


> * 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.
>

Sure.  To be honest, I didn't even notice that there was a synchronous
decode method until you raised this.


> * 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.
>

This is the one that radically concerns me, as it would have HUGE
implications for the shape of the API and compatibility.  I feel like the
thrashing from such changes would be at least as large as the changes we're
talking about now (the naming changes that have already gone in), and our
collective opportunity to change such things is fading.

As I think I previously mentioned, I actually don't think constructors is a
good idea here (as most of the nodes have a direct relationship with the
context).

Other than decoding - and there, honestly, I think there's room for a
fuller API in the future - and possible getUserMedia, nothing leaps to mind
that needs Promises.

Is there any way we can quantify and address any such issues ASAP, because
I think we need to be talking about large changes before small ones.

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.
>

I think that Chris recognizes the duplicate-naming issues, and Apple's
(declared) support for making these changes certainly helps strengthen the
case.  I won't speak for Chris, but I will say the issues under #4 _I'm_
not supportive of (and I tend to be more cowboy than Good Chris.:)  (Note
this is "I don't see the justification for this," not "over my dead body.")

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...
>

The longer you delay shipping an unprefixed implementation, the more
cemented use of webkitAudioContext becomes.  That's not being flip, it's
just being realistic; authors don't have any encouragement to do it the
right way today.  Blink or Webkit could ship unprefixed - but frankly, the
other issues above are leavcing me more concerned about making that change
now.


> 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.
>

No, the final incentive for people to move their code to the standard API
is that it will actually WORK in a lot more browsers, interoperably, and
they're being told exactly how to do that through evangelism efforts, and
coding references tell them the right way.  This is a powerful incentive,
despite being a carrot not a stick.

-Chris