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

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