Re: Sites using webkitAudioContext only

On Mon, Jun 17, 2013 at 6:26 PM, Chris Wilson <cwilso@google.com> wrote:

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

Note that this I don't agree with Robert that this is not a very serious
problem.  I've already seen some people complain about Web Audio demos to
be slow to load or to "lock up" the browser, and in almost every case it's
AudioContext.createBuffer, often with multi-hundred millisecond pauses on
reasonably fast desktop machines, when loading lots of assets.  The
situation is going to be a lot worse on mobile devices.


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

You can just pass in the context to the constructor, so this is not really
a huge issue.

It's true that we can standardize Web Audio with these C-style creator APIs
and things will work in practice, but we will end up with a non-webby API.
That's not a deal breaker, but we have the potential to fix this problem
now if all of the three engines implementing Web Audio cooperate.
Otherwise, I don't have a lot of hope of this being possible in a V2 of the
spec -- that is, we might spec and implement a better API, but the damage
of the current API will be done for everybody who has already learned and
used the API, and it will ripple through other web developers for some time.


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

If we fixed all of the other issues and only left this one unresolved, I
would be a happy man!


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

Hmm, not sure what you mean by quantify -- we can't do that without data,
which we don't have.


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

I was only talking about delaying for one release, that is, 6 weeks.  That
will most likely only be necessary if we adopt the larger scale changes to
the API.


> Blink or Webkit could ship unprefixed - but frankly, the other issues
> above are leavcing me more concerned about making that change now.
>

Which change are you referring to?


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

Interoperability is orthogonal here, we're having all of this conversation
to maintain that.  We should definitely strive to have interoperable
unprefixed AudioContext implementations.

Most of the carrots we can offer web developers are evangelism efforts.
I'm not aware of any such efforts having started so far, so honestly I'm
not holding my breath for it to suddenly start happening now.  The stick,
however, is the prefixed implementation.  Chrome can either use that to
unprefix AudioContext and remove the webkitAudioContext as soon as
possible, or to make other engines conform to what it's currently
shipping.  So far it has been using it in the latter direction.  I remember
from the f2f conversations (please correct me if I'm wrong) that Chris
Rogers was against removing webkitAudioContext for a long period of time
(possibly 1-2 years if I remember the conversation correctly), which really
worries me.

This all being said, I think we've talked about all of the possible
directions we can possibly take quite extensively thus far.  Let's give
Chris Rogers a chance to catch up with the thread and comment on it, and
then we can discuss which path forward we should be taking.

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