On Thu, Jun 20, 2013 at 4:21 PM, Robert O'Callahan <robert@ocallahan.org>wrote: > 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. > I agree with most of this, especially the part about "limiting the scope of compatibility-affecting changes for the unprefixed AudioContext to those that are either trivial or essential". The "races" issue for AudioBuffers I do not agree with. We can't be in a situation where we're copying-data/duplicating/neutering large PCM data buffers each time we play a sound. These buffers are often quite large, and it's common to re-trigger the same sound (from the same buffer) rapidly in succession for game sound effects, synthesizers, etc. > 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:44:37 UTC