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

Ehsan,

I haven't seen any objection to your two proposals below.

On #1 there is a counter-proposal by Chris Rogers, which is still being discussed.

On #2 I'd like to give everyone at least week (starting from your proposal) to object, after which we can consider that there is indeed consensus.

All - please chime in on the two proposals by Friday:
http://lists.w3.org/Archives/Public/public-audio/2013AprJun/0634.html

--
Olivier

On 24 Jun 2013, at 23:04, Ehsan Akhgari <ehsan.akhgari@gmail.com> wrote:

> So, am I correct to assume that we all agree on #1 and #2 below?
>
> Thanks!
>
> --
> Ehsan
> <http://ehsanakhgari.org/>
>
>
> On Fri, Jun 21, 2013 at 2:26 PM, Ehsan Akhgari <ehsan.akhgari@gmail.com> wrote:
> On Thu, Jun 20, 2013 at 8:57 PM, Chris Rogers <crogers@google.com> wrote:
>
>
>
> 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.
>
> Sure.  It seems like we're all clear that this section of the spec is not targeted at implementers.  I think that we should really be pointing web developers to actual documentation, but that is an orthogonal goal.
>
> --
> Ehsan
> <http://ehsanakhgari.org/>
>

--
Olivier Thereaux - BBC Internet Research and Future Services






-----------------------------
http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and
may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in
error, please delete it from your system.
Do not use, copy or disclose the
information in any way nor act in reliance on it and notify the sender
immediately.
Please note that the BBC monitors e-mails
sent or received.
Further communication will signify your consent to
this.
-----------------------------

Received on Tuesday, 25 June 2013 09:38:52 UTC