Re: WaveShaperNode.curve

On Thu, May 16, 2013 at 7:31 PM, Robert O'Callahan <robert@ocallahan.org>wrote:

> On Fri, May 17, 2013 at 11:18 AM, Frederick Umminger <
> frederick.umminger@gmail.com> wrote:
>
>> I don't get this backward compatibility limitation. The WebAudio API is
>> not a standard yet.  Any developer writing to the API is knowingly writing
>> to something not yet standardized.
>>
>
> Unfortunately that's a bad assumption. Many developers writing to the API
> have simply been told it's the future and they should use it.
>
>
>> Why is there any duty at all not to break their code?
>>
>
> If person A writes bad code and user B tries it in browsers C and D and it
> works in browser C but not D, then B blames D, not A. That, not "duty", is
> the incentive for D to ensure A's code works.
>
> If you don't want your code broken, you act as a responsible developer and
>> write to the standardized APIs, not the APIs that are explicitly
>> experimental and under development. If you write to an experimental API and
>> then complain because your code broke, then you are just a big cry-baby.
>>
>
> Whatever you want to call them, they're still a problem for browser D.
>
>  By accepting this constraint of backwards compatibility, we are
>> crippling the WebAudio API by limiting it to whatever was first
>> implemented. That is not the way the standards process is supposed to work.
>> The implementations are supposed to allow explorations of the proposed APIs
>> in real-word scenarios in order to ensure their quality before they become
>> solidified into an immutable standard. It seems to me we are doing this
>> exactly backwards, and baking in known flaws.
>>
>
> Indeed.
>

Frederick, I whole-heartedly agree with your concerns, but please note that
the usual process of developing web standards will only work if the browser
engines implementing the experimental spec do treat that as experimental
technology that is subject to change.  WebKit doesn't do that, and for all
intents and purposes treats webkitAudioContext as a standard feature which
should never break backwards compatibility, and unfortunately Blink has
adopted the same policy regarding webkitAudioContext.  The current Web
Audio spec is full of things which are clearly bad ideas (alternate names,
numeric enums, AudioBufferSourceNode.gain, using creator methods on
AudioContext instead of constructors, etc.), but we cannot break them
because of this reason.  What we're trying to do is at least keep the API
free of footguns such as data race issues, but the way I see things, with
the current state of matters, we don't have a good pathway towards fixing
most of the API issues in Web Audio. :(

--
Ehsan
<http://ehsanakhgari.org/>