Re: Sites using webkitAudioContext only

On Wed, Jun 12, 2013 at 1:01 AM, Ehsan Akhgari <ehsan.akhgari@gmail.com>wrote:

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

I agree with all of this, and that's coming from someone who respects and
enjoys the overall current design. The block processing system is
fantastic, but the API is not. We can make it better backwards compatibly
too, should compatibility be shown to be a huge issue with real-world data
(which these discussions do not seem to have included to date).


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

...that's incredibly frustrating to hear. The WebKit world was different
than the Blink world; Chris: do you think we have the ability to make these
changes now?


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

>From my perspective on TC39 and the TAG, it seems like unprefixing is the
final chance to walk these decisions back and make final clean-ups. And
that's not really related to the spec process except that they are highly
correlated.

I urge everyone here to take a second look: *can* the surface area for
normative names be reduced? *Can* the create*() APIs be walked back in
favor of constructors? *Can* the iterop story with the <audio> element be
improved? If the practical answer, based on real-world usage is "yes", then
now's the time.


> I still believe that Web Audio is still not nearly as widely used as most
> other web APIs,
>

It's certainly not as widely used as many engine-specifc JS bugs and
features which we are walking back/change over in TC39 land. As Yehdua
said, "where's this magical land of compatibility? I build stuff on the
edge of the platform and it breaks and changes all the time."

Lets not tie ourselves down based on a promise that nobody is practically
asking us to keep.


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