Re: WaveShaperNode.curve

On Thu, May 16, 2013 at 8:20 AM, Ehsan Akhgari <ehsan.akhgari@gmail.com>wrote:

> buffer passed to it, and then the whole problem would be solved without
> the need to resort to neutering.  However, this won't work in practice
> since WebKit/Blink is not willing to implement this kind of backwards
> incompatible change, and unfortunately that's currently the API most people
> are targeting, so we either have the choice of spec'ing the correct thing,
> and then have Gecko implement the spec and WebKit/Blink continue to ignore
> the spec and hence end up with non-interoperable implementations (which
> means you have to write your code once for WebKit/Blink and once for Gecko
> and future spec-compliant implementations) or we have to resort to
> neutering tricks to break code which is currently relying on the data race
> behavior (even unknowingly) even though that makes for a less than pleasant
> API.
>
> This line of issue has come up several times on this list, and we
> discussed this extensively at the Audio working group face to face as
> well.  Unfortunately, without WebKit/Blink willing to change their
> implementation in backwards incompatible ways, given the fact that those
> engines are currently the "de facto" standard, we need to resort to these
> kinds of tricks to keep backwards compatibility but remove problems such as
> data races.  This makes me very sad, but really there is only so much that
> we can do about this on the Gecko and spec side of things.  :(
>



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. Why is there any duty at all not to break
their code? 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.

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.

-Frederick