Re: Use of both numbered constants and strings

On Tue, Apr 16, 2013 at 11:51 PM, Marcus Geelnard <mage@opera.com> wrote:

> **
> Den 2013-04-16 23:20:04 skrev Chris Rogers <crogers@google.com>:
>
>
>
>
> On Mon, Apr 15, 2013 at 10:36 AM, Simon Pieters <simonp@opera.com> wrote:
>
>> Hi
>>
>> https://dvcs.w3.org/hg/audio/raw-file/tip/webaudio/specification.htmlsays
>>
>> [[
>> Some attributes taking constant values have changed during API review.
>> The old way uses integer values, while the new way uses Web IDL string
>> values. An implementation must support both integer and string values for
>> setting these attributes:
>> // PannerNode constants for the .panningModel attribute
>>
>> // Old way
>> const unsigned short EQUALPOWER = 0;
>> const unsigned short HRTF = 1;
>> const unsigned short SOUNDFIELD = 2;
>>
>> // New way
>> enum PanningModelType {
>>   "equalpower",
>>   "HRTF",
>>   "soundfield"
>> };
>> ]]
>>
>> I'm not quite happy about the spec supporting both the legacy way and the
>> new way. AFAIK no other API supports both. In HTML, for APIs that are
>> widely used and thus can't have the numbered constants removed, the API
>> only supports the legacy constants (can't come up with an example right
>> now). For APIs that are not widely used yet and thus can be changed in
>> incompatible ways, the APIs were changed to only support the strings (e.g.
>> TextTrack.mode).
>>
>> Is Web Audio API widely used? Please consider choosing between "old way"
>> and "new way". I think supporting both will be confusing for authors.
>
>
> Simon, yes we consider it widely used as there are both Chrome Apps (Angry
> Birds, etc.), and iOS/Safari apps  which are shipping.
>
> We had a very long discussion about this at the audio face-face meeting
> this year, so this is what we have.
>
>
> Jumping into discussion again...
>
> I understand that there might be a problem with supporting old WebKit Web
> Audio apps, but I still fail to see why this kind of legacy support has to
> be part of the spec.
>
> Isn't it true that legacy apps use the webkit prefixed version of the API?
> Why not keep all the "alternate" parts of the API in the prefixed name
> spaces, and let the un-prefixed (spec compliant) API entries be clean (i.e.
> only supporting the "new" way)? IMO, the same reasoning can be applied to
> section 20 in the spec too.
>

The reason is because a lot of pages check for AudioContext first and
construct that, then fallback to webkitAudioContext, etc.  So the pages
would still be broken...



>
> I'm sorry that I missed the f2f discussion on this, so could someone
> please explain why the current approach of supporting both the old and the
> new names/ways was selected?
>
> /Marcus
>
>
>
> Chris
>
>
>
>
>>
>>
>> --
>> Simon Pieters
>> Opera Software
>>
>>
>
>
>
> --
> Marcus Geelnard
> Android Browser Developer
> Opera Software ASA
>