W3C home > Mailing lists > Public > public-audio@w3.org > April to June 2013

Re: Sites using webkitAudioContext only

From: Robert O'Callahan <robert@ocallahan.org>
Date: Fri, 21 Jun 2013 11:21:44 +1200
Message-ID: <CAOp6jLbL7T=Wt=8gHwZELQ7pLKZ8Ab09cRjWW5rurMjm=9So=A@mail.gmail.com>
To: Chris Wilson <cwilso@google.com>
Cc: Ehsan Akhgari <ehsan.akhgari@gmail.com>, Kevin Gadd <kevin.gadd@gmail.com>, Marcus Geelnard <mage@opera.com>, Chris Rogers <crogers@google.com>, Chris Lowis <chris.lowis@bbc.co.uk>, Olivier Thereaux <Olivier.Thereaux@bbc.co.uk>, "public-audio@w3.org" <public-audio@w3.org>, Alex Russell <slightlyoff@google.com>
On Fri, Jun 21, 2013 at 4:34 AM, Chris Wilson <cwilso@google.com> wrote:

> I would say I would like to not continue to bikeshed issues like
> constructors vs creators for an unspecified period of time, and that
> changes on that level should not be considered without strong need.
>  Removing alternate names is not a problem.
>
> On Wed, Jun 19, 2013 at 1:42 PM, Ehsan Akhgari <ehsan.akhgari@gmail.com>wrote:
>
>> The only implementation which currently has an unprefixed implementation
>> which is close to shipping is Gecko, and I've said many times in this
>> thread that I'm open to delay shipping Web Audio in Firefox if we end up
>> making a large number of changes in order to improve the API.
>>
>
> Yes, which I think is the right thing to do.  But simultaneously, I feel
> that pressure is being placed on Blink to remove its current somewhat
> stable webkitAudioContext, and to sign up for an unbounded set of changes
> to the API.
>

I agree that we shouldn't be doing that.

I'm in favour of limiting the scope of compatibility-affecting changes for
the unprefixed AudioContext to those that are either trivial or essential,
and setting a hard, short deadline for finalizing that list --- 1-2 weeks.
I think that list should be:
-- Everything that's already in the spec
-- Remove obsolete names. Ehsan will provide the precise list shortly.
-- Remove AudioContext.createBuffer(AudioBuffer)
-- Fixes to prevent races caused by changes to "live" AudioBuffers. I can
provide a proposal for this today, based on what we've already implemented.

Promise-based APIs can be added later in addition to the direct-callback
APIs, without much pain, so I'd drop them for now. Using constructors
instead of factory methods is cosmetic and I don't think it's worth
changing those at this point.

Rob
-- 
Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le
atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o Whhei csha iids teoa
stiheer :p atroa lsyazye,d 'mYaonu,r "sGients uapr,e tfaokreg iyvoeunr, 'm
aotr atnod sgaoy ,h o'mGee.t" uTph eann dt hwea lmka'n? gBoutt uIp waanndt
wyeonut thoo mken.o w
Received on Thursday, 20 June 2013 23:22:11 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:50:08 UTC