- From: Jan-Ivar Bruaroey <jib@mozilla.com>
- Date: Thu, 22 Jan 2015 14:11:29 -0500
- To: public-script-coord@w3.org
On 11/6/14 4:28 PM, bugzilla@jessica.w3.org wrote: > https://www.w3.org/Bugs/Public/show_bug.cgi?id=27048 Hi all, There's a case in WebRTC where we've instinctively defined the webidl enum RTCStatsType for types of dictionaries returned from getStats(). [1] Since these are not living documents, other specs may want to extend what stats a browser can return in the future - without having to update webrtc-stats - so the group finds itself considering reverting RTCStatsType to DOMString to allow for this [2]. While an argument can probably be made that this is fair, going with DOMString looses all the documentation and referencing benefits that seemed inherently good - and still seem good - about having an RTCStatsType in the first place. Furthermore, the reason for the limitation only seems to make sense in the spec space, not the implementation space (farewell binding code) or usage space. A plain string looses the idea that there are special strings that have defined meanings. We also lose a place for other specs to link to when they extend the definition, e.g. another spec might make up a string without reference. Is there room for a construct in-between string and enum here? A partial enum? Other solutions? RTCStatsType is not used as an input. .: Jan-Ivar :. [1] http://w3c.github.io/webrtc-stats/#idl-def-RTCStatsType [2] https://lists.w3.org/Archives/Public/public-webrtc/2015Jan/0068.html
Received on Thursday, 22 January 2015 19:11:58 UTC