Re: Sites using webkitAudioContext only

On Tue, Jun 11, 2013 at 7:44 PM, Chris Wilson <cwilso@google.com> wrote:

> On Tue, Jun 11, 2013 at 4:08 PM, Ehsan Akhgari <ehsan.akhgari@gmail.com>wrote:
>
> On Mon, Jun 10, 2013 at 12:23 PM, Chris Wilson <cwilso@google.com> wrote:
>>
>>> I would actually strongly suggest that developers use a monkey patch
>>> library, like my paired set:
>>>
>>> https://github.com/cwilso/AudioContext-MonkeyPatch: This library should
>>> be used for new projects, which are written to the official Web Audio
>>> specification, and it should monkey-patch the calls on systems that may not
>>> support the most modern definitions (e.g. patching AudioContext to
>>> webkitAudioContext, and start() calls get patched to call noteOn()).  You
>>> could use this, for example, to get a properly written Web Audio app to
>>> work on iOS today.
>>>
>>
>> I'm not sure how useful this is for the Safari problem, but as far as
>> Gecko is concerned, we fully support all of the alternate names mandated by
>> the spec, so if you just switch to using AudioContext, then everything
>> should work (including noteOn/noteOff, setTargetAtTime, etc.)
>>
>> Can you please modify this library so that it doesn't touch
>> AudioContext?  I don't believe any of the AudioContext monkey-patching is
>> necessary any more.
>>
>
> Umm, no, that's the point of the library - otherwise, you CAN just do
> audioctx = AudioContext || webkitAudioContext.  But read on...
>
>
>>  https://github.com/cwilso/webkitAudioContext-MonkeyPatch: This library
>>> can be used for old apps, written to webkitAudioContext implementations, to
>>> get them working on proper spec-compliant implementations of AudioContext
>>> (e.g. Firefox), without having to rewrite all your code.  This is kind of a
>>> cheap way to do this (obviously, for any significant app you should likely
>>> revise your code), but it makes it quick and easy to get old code working
>>> on Firefox if nothing else.
>>>
>>
>> Given the above, all you have to do is to use the AudioContext
>> constructor, and fall back to webkitAudioContext if that's not available.
>>
>
> I'm afraid I'm confused by what you want.  I'm going to share my personal
> thinking here, but understand that Chris Rogers and I disagree somewhat on
> some of the finer points, so this is not "the Google opinion".
>
> I personally think long-term, having "alternate names" is significant
> badness.  If they're important enough to implement everywhere, just use
> them; if your concern is just that your standard-following implementation
> doesn't "work" for all those webkitAudioContext, noteOn()-using apps out
> there right now, let's attack that problem together with some monkeypatch
> libraries and some evangelism.  If you're just going to implement them all
> anyway, then why do we change names and confuse developers by giving them
> two methods to do the same thing, that differ only in name?  The
> monkeypatch libraries, on the other hand, let us make these kind of changes
> and fix it up in the short term, letting developers be "clean".
>
> My personal belief is the "alternate names" should be removed from the
> spec long-term, as we migrate all the implementations out there to support
> the new names (obviously, iOS Safari is the least-known quantity here).  In
> the meantime, we can use evangelism of monkeypatching libraries to hide the
> implementation complexities across different browsers, and as we roll
> Chrome into unprefixed AudioContext, I would hope we could start removing
> some old stuff.  (Yes, this is where Chris and I disagree, I believe.)  I
> had not realized you were just implementing all the old names in Firefox.
>
> We have the unfortunate and difficult task of having multiple browsers
> implement the old names, under prefix, and a fair bit of legacy content
> that we do not wish to break, as well as the task of good stewardship for
> the long term.  I still think we have the opportunity to fix the long term
> without destroying the short term, but if I'm the only one who believes
> that's the approach we should take, I'll just delete those two monkeypatch
> repos and developers can use the || approach.
>

No, you're not the only person thinking that.  I agree that having
"alternate names" is significant badness.  Really, Web Audio in its current
form is not a great web spec.  It should probably use constructors instead
of creator functions, have a better interface for recording playback rather
than OfflineAudioContext, and probably have a singleton "context" object,
etc.  The reason that we are stuck with "alternate names" and all of the
rest of the API badness in Web Audio _is_ Blink/WebKit resisting changing
most of the APIs.  (Actually most of this discussion was before Blink was
publicly announced, and from what I know resisting this is actually in
contrast to the new Blink policy, but Chris Rogers probably knows those
rules better than I do...)

I initially resisted implementing the alternate names in Gecko, and I was
planning on resisting to implement some of the other bad ideas in the Web
Audio spec (such as the synchronous createBuffer override), but I changed
my position given the developer feedback of "Web Audio not working in
Firefox Nightly", etc.  For better or worse, Google pushed
webkitAudioContext as _the_ Web Audio standard to use way before the API
was looked at by other browser vendors, and now we're stuck with these
issues because WebKit/Blink will not accept "breaking" changes to their
implementation, and IIRC Chris Rogers said that even when it's unprefixed,
he's planning to maintain backwards compatibility with webkitAudioContext
APIs.

I still believe that Web Audio is still not nearly as widely used as most
other web APIs, and the only engines shipping it have implemented it with a
prefix.  We still have time to fix this, but we need buy-in from
WebKit/Blink (or at least Blink).  If we get that buy-in, I will work on
adoping all changes to the spec in Gecko, even if it means that we would
need to delay shipping this in Firefox, since I believe that shipping a
better API is better than shipping a bad API sooner,

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