Re: Sites using webkitAudioContext only

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.

-C