Re: Sites using webkitAudioContext only

Hi, folks-

FWIW, I strongly agree with Chris Wilson here. Perpetuating multiple 
aliases, especially across multiple browsers, is going to confuse 
authors and is a Bad Thing in general.

The correct response to bugs that are using API the wrong/outdated way 
is not to change the browser, it's to provide good documentation on how 
to use the API the right way, and to provide script libraries like 
Chris' monkeypatch.

I do think it would be a good idea for us to collect a list of sites 
that are known to use the webkit-only API names, so we can contact them 
and coordinate updating their code. We could do this on our wiki, or 
elsewhere... what do y'all think?

Regards-
-Doug

On 6/11/13 7:44 PM, Chris Wilson wrote:
> On Tue, Jun 11, 2013 at 4:08 PM, Ehsan Akhgari <ehsan.akhgari@gmail.com
> <mailto:ehsan.akhgari@gmail.com>> wrote:
>
>     On Mon, Jun 10, 2013 at 12:23 PM, Chris Wilson <cwilso@google.com
>     <mailto: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

Received on Wednesday, 12 June 2013 20:00:52 UTC