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

On Tue, Jun 25, 2013 at 5:38 AM, Olivier Thereaux <
Olivier.Thereaux@bbc.co.uk> wrote:

> 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.
>

Do you mean the issue of whether we should keep the mention of the old
names in the spec?  It's ok to keep discussing that, but the main things
I'm seeking for consensus on is whether those names are removed from the
normative text of the spec, and I don't believe there is a counter-proposal
to that part of the issue.


> 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
>

Great, thanks again!

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



> --
> 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.
> -----------------------------
>