W3C home > Mailing lists > Public > public-audio@w3.org > April to June 2013

Re: Consensus on the issue of deprecated APIs and sync decoding

From: Chris Rogers <crogers@google.com>
Date: Thu, 20 Jun 2013 17:57:25 -0700
Message-ID: <CA+EzO0n5GjfjYkNZVLW-KqLvg0eh+C5pOQEEcAx5jCfbds=s_g@mail.gmail.com>
To: Ehsan Akhgari <ehsan.akhgari@gmail.com>
Cc: Joe Berkovitz <joe@noteflight.com>, "public-audio@w3.org" <public-audio@w3.org>
On Thu, Jun 20, 2013 at 5:50 PM, Ehsan Akhgari <ehsan.akhgari@gmail.com>wrote:

> On Thu, Jun 20, 2013 at 8:16 PM, Joe Berkovitz <joe@noteflight.com> wrote:
>> 1. I propose that we should remove this section <
>> https://dvcs.w3.org/hg/audio/raw-file/tip/webaudio/specification.html#OldNames>
>> from the spec, and any AudioContext implementation should not implement
>> those names.  If we get consensus on this, I will create a porting guide
>> documentation on MDN to help authors port their old content.  We can
>> mention the monkey patching library etc in that article, and make it really
>> useful for web developers.
>> It seems to me that this section of the spec is already no more than a
>> porting guide. I favor retaining it for a while because it makes the
>> transition to the new names easier for developers, which I think we all
>> want.
>> Ideally MDN could also have a porting guide which I don't imagine would
>> have very different content. Wouldn't having both be the best?
>> Keeping historical notes in the spec seems weird.  I think that we should
> move such content to developer documentation resources that we have.  The
> content would need to be modified to frame it as a guide to port code
> written against webkitAudioContext to code written against standards based
> AudioContext, and include code samples, monkey patching code, etc.

Can we have a compromise, where the section is retained during a
transitional period?  In the long run I can see why it would be removed,
but I think you underestimate the number of developers who look to the spec
for guidance.  Considering that these name changes will impact a large
number of developers for all the browser vendors, it seems like we'd just
be adding additional obstacles to them discovering the changes that we're
making and adapting appropriately if the information is not even there.


> Cheers,
> --
> Ehsan
> <http://ehsanakhgari.org/>
Received on Friday, 21 June 2013 00:57:52 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:03:18 UTC