W3C home > Mailing lists > Public > public-webrtc@w3.org > August 2013

Re: Stats variables - some more input

From: Harald Alvestrand <harald@alvestrand.no>
Date: Mon, 12 Aug 2013 10:21:13 +0200
Message-ID: <52089AF9.2080900@alvestrand.no>
To: Jan-Ivar Bruaroey <jib@mozilla.com>
CC: "public-webrtc@w3.org" <public-webrtc@w3.org>
On 08/06/2013 05:57 PM, Jan-Ivar Bruaroey wrote:
> I think this looks great - I'm working on implementing this for 
> Firefox, so I appreciate all the good info!
> I have a few general comments on the webidl to start (sorry if this is 
> outside the scope of your post).
> Our webidl guy (behind our webidl compiler), had two concerns with the 
> spec that he shared with me:
> The first was the polymorphism implied in the RTCStats-derived 
> dictionaries returned. He thinks webidl wont work that way and that 
> any bindings generated (for c++ for instance) from this as written, 
> will only ever return timestamp, type and id this way, and none of the 
> derived fields. I think this can be circumvented using a union:
>   typedef (RTCStats or
>            RTCRTPStreamStats or
>            RTCInboundRTPStreamStats or
>            RTCOutboundRTPStreamStats or
>            RTCMediaStreamTrackStats or
>            MediaStream or
>            RTCTransport or
>            RTCIceComponentStats or
>            RTCIceCandidatePairStats or
>            RTCIceCandidate or
>            RTCCodec) AnyRTCStats;
> and have the API return AnyRTCStats.

Yes, WebKit has this issue too, which leads to convoluted stuff. We 
solved a similar situation elsewhere by telling WebIDL that the API 
object was an Object with a custom getter, rather than a dictionary (and 
then waiting for Blink / WebIDL to support dictionaries better.

The union defeats our purpose, since it limits the legal forms of stats 
to just those that made it into the union; we want to be able to add new 
stats at will, including implementation-defined ones.

> The second point was that getters apparently have name collision 
> issues, and he was wondering if it would be better for our needs to 
> return a (read-only) "Map-like" object 
> http://dev.w3.org/2006/webapi/WebIDL/#MapClass like this:
>   [MapClass(DOMString, AnyRTCStats)]
>   interface RTCStatsReport {};

This seems like an interesting direction to go - would this be instead 
of using Dictionary?
Which interfaces today utilize the [MapClass] extended attribute? (I 
like to look at examples...)

BTW, shouldn't it be MapClass(DOMString, DOMString or Integer or ....) 

> A third comment from someone else was that we could use interfaces 
> here, which would give us inheritance (to avoid the long and growing 
> typedef above), though that seems like overkill, to me, for data 
> that's never passed back to the browser, but I wanted to mention it.
> ---
> I have no specific comment on the specific fields yet, except that the 
> naming seems to be inconsistent in a few places. For instance, I would 
> have expected "RTCMediaStreamStats" rather than "MediaStream" etc. Are 
> those short-hands or typos?

Probably a combination of both.
Received on Monday, 12 August 2013 08:21:01 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:35 UTC