On #1 - it was actually a design goal for me to not provide both sets of
names. I wanted one library that would give you the new names if they
didn't exist (including unprefixed) to include if the user was using a
browser that didn't support the standard as writ, and a different library
if you were just quickly patching an app written to webkitAudioContext.
Those were two different goals, to me.
On Thu, Jun 20, 2013 at 6:52 PM, Srikumar Karaikudi Subramanian <
srikumarks@gmail.com> wrote:
> Hi,
>
> A couple of points -
>
> 1. I noticed that Chris Wilson's AudioContextMonkeyPatch is only one way.
> This is not what I need
> because it doesn't patch AudioContext in un-prefixed implementations. So I
> made one for my
> own use since I do have legacy code that I can only port over time .. if
> anyone's interested.
>
> https://gist.github.com/srikumarks/5780007
>
> This patch will provide new names in implementations that have only the old
> names and will provide old names in implementations that have only the
> new names. It will provide both the prefixed and unprefixed AudioContext
> constructor if either is missing. On top of that, it will emit deprecation
> warnings
> for the old names upon use (only once) and urge you to move to new API
> names
> right away. This is exactly what *I* (as a dev) need to save myself time
> checking
> whether my code will work in various browsers (Blink, Opera, Mozilla)
> whenever
> they come out.
>
> 2. I think Mozilla "being forced to include webkitAudioContext" just to
> run
> existing code is a failed argument if neutering is already implemented to
> solve
> race conditions. Much of my code won't run, even with the above linked
> bi-directional
> monkey patch. I'm quite sure there are others like me. A "good" solution
> to this problem
> (imho) is to use immutable objects (ex: Blobs) instead of (or in addition
> to) ArrayBuffers,
> but I believe the decision is already made?
>
> Best,
> -Kumar
> http://sriku.org
>
>
> On 21 Jun, 2013, at 5:25 AM, "Robert O'Callahan" <robert@ocallahan.org>
> wrote:
>
> On Fri, Jun 21, 2013 at 11:44 AM, Chris Rogers <crogers@google.com> wrote:
>
>> 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.
>>
>
> We're not neutering AudioBuffers --- you can use them over and over again
> without copying. We're neutering the ArrayBuffers used to create the
> AudioBuffers.
>
> 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
>
>
>