- From: Cullen Jennings <fluffy@cisco.com>
- Date: Thu, 12 Jan 2012 09:10:20 -0700
- To: Harald Alvestrand <harald@alvestrand.no>
- Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>
I think we should do whatever Hickson is going to do for HTML5 spec. On Jan 10, 2012, at 2:10 AM, Harald Alvestrand wrote: > 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], this: > > 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 Thursday, 12 January 2012 16:40:39 UTC