Re: Sites using webkitAudioContext only

Den 2013-06- 22:33:38 skrev Ehsan Akhgari <ehsan.akhgari@gmail.com>:

>
> On Sat, Jun 15, 2013 at 12:45 PM, Chris Wilson <cwilso@google.com> wrote:
>> On Fri, Jun 14, 2013 at 4:17 PM, Robert O'Callahan  
>> <robert@ocallahan.org> wrote:
>>
>>> On Sat, Jun 15, 2013 at 9:45 AM, Chris Wilson <cwilso@google.com>  
>>> wrote:
>>>> We are open to removing the old names from Blink; however, I expect  
>>>> we will begin by offering a clean unprefixed version, and work hard  
>>>> at >>>>evangelizing to move developers over to that standards  
>>>> implementation; we can then remove the prefixed version at some point  
>>>> in the future (after >>>>doing console warnings, etc., to deprecate  
>>>> its usage).
>>>
>>> The problem is that this all needs to be done very soon.
>>
>> Indeed, I can understand why this is time-critical for Mozilla, as you  
>> need to make decisions before shipping.  That's why I'm even MORE  
>> concerned >>about the introduction of the possibility of "more drastic  
>> changes", because any even medium-sized changes (and definitely  
>> something as major as >>changing the constructor pattern) is going to  
>> change this discussion.
>
> Here are the three categories of things which I would like to see  
> changed in the current spec:
>
> * Having more than one way to do things in the API.  This is mostly the  
> question of the alternate names which we're currently discussing.
> * Ways in which the API design introduces data race possibilities.  This  
> includes things such as allowing read-back from buffers used by the  
> audio >processing code, such as WaveShaperNode.buffer,  
> AudioBuffer.getChannelData, etc. as previously discussed on the list.   
> Removing these read-back >mechanisms would make it possible to use  
> copy-on-write techniques in order to make sure that we avoid copies  
> where we can, and that web content will >not be allowed to do things  
> which introduce data races.
> * 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.
> * 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.

Technically, that sounds like four categories ;-)

I would like to add that there are still some pretty awkward interfaces in  
the API (might fall under the last category, or in a separate  
"consistency/clean up" category?). In particular, not much has happened to  
the AnalyserNode (except for changing names from RealtimeAnalyserNode):  
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17361


-- 
Marcus Geelnard
Technical Lead, Mobile Infrastructure
Opera Software