W3C home > Mailing lists > Public > public-webrtc@w3.org > January 2012

CHANGE: Remove numeric constants from WebRTC API

From: Harald Alvestrand <harald@alvestrand.no>
Date: Tue, 10 Jan 2012 10:10:32 +0100
Message-ID: <4F0C0088.3070400@alvestrand.no>
To: "public-webrtc@w3.org" <public-webrtc@w3.org>
Hello group, and happy 2012!

One of the last discussions of 2011 was the discussion triggered by Tab 
Atkins about numeric constants in the API: he strongly recommended 
against them, and recommended that we instead use strings (possibly in 
the special form of WebIDL enumerations, which are mapped to JavaScript 
strings by the language binding.

It seems to me clear from the discussion that:

- The WebIDL community is strongly in favour of such a change
- There has been weak or no real opposition to the idea in the WebRTC WG
- If such a change is to be made, it is better to do it as soon as 
possible, so that implementations don't have to change after significant 
deployment of code has been made.

But it's a bit of work, and I don't want to ask the editors to do it if 
there's the possibility that the WG could decide not to do it anyway.

I'm therefore calling for the WG's consensus to do this change.
It affects at least the following:

- MediaStreamTrack: readyState (LIVE, MUTE and ENDED)
- PeerConnection: readyState, iceState and sdpState

In all four cases, the current "const unsigned short" declarations woudl 
be replaced with strings; as I understand the enum spec from WebIDL [1], 

     const unsigned short LIVE = 0;
     const unsigned short MUTED = 1;
     const unsigned short ENDED = 2;
     readonly attribute unsigned short readyState;

would become this:

     enum ReadyStateType { "live", "muted", "ended" };
     readonly attribute ReadyStateType readyState;

Please comment on this - the chairs will attempt to draw a conclusion 
based on mail arrived on Tuesday, Jan 17, at 9AM GMT (7 days from now).

                    Harald, for the chairs

[1] http://dev.w3.org/2006/webapi/WebIDL/ - latest draft 5 Jan 2012
Received on Tuesday, 10 January 2012 09:11:01 UTC

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