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.

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