Re: Stats variables - some more input

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 ....) 
above?

>
> 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