Re: Summary of stats discussion in Boston

On 02/13/2013 11:31 PM, Martin Thomson wrote:
> In terms of dealing with the RTCStatsReport in WebIDL, named
> properties are what is called for:
> http://www.w3.org/TR/WebIDL/#idl-named-properties
>
> interface RTCStatsReport {
>    getter RTCStatsObject (DOMString identifier);
> };
>
> The mandatory "list of supported properties" that the spec is required
> to use is "the set of object identifiers currently in use for the
> RTCPeerConnection", where the "Object identifiers are allocated by the
> browser, and must be unique within the scope of a RTCPeerConnection".
I like this!
>
> Note that RTCRTPStreamStats could be a dictionary or an interface.
> Sure, using a dictionary implies ordering, but in all seriousness, who
> is going to check that your enumerator puts ssrc before otherEndStats?
>   On the other hand, interface implies the availability of lots of
> other features.
Which ones?

My reason to avoid implementing Dictionary was to avoid "promising" 
features I didn't need and didnt want to support. If Interface is worse 
in this regard, that argues for avoiding it.

>    If you use interface, you should probably tag it
> [NoInterfaceObject] so the global namespace isn't polluted
> unnecessarily.  Once you do that, it's pretty hard to tell if it was
> interface or dictionary.

[NoInterfaceObject] seems natural if using Interface, also to keep down 
the size of the promise given.
I intend to implement all stats as one class in WebKit with a getter, no 
matter what the spec will come out saying; I think it's possible to fake 
all the other properties that might be needed, but the less work I have 
to do in doing so, the better.

>
> On 7 February 2013 09:07, Justin Uberti <juberti@google.com> wrote:
>> Here is a summary of what I *think* we decided to do in WEBRTC regarding
>> stats this morning.
>>
>> Proposal:
>>
>> getStats(selector, cb) gives you back (in the callback) a RTCStatsReport
>> (unchanged from previous proposal).
>>
>> RTCStatsReport now becomes a map<id, RTCStatsObject>; you can look up a
>> report by id, or iterate over them all.
>>
>> The RTCStatsObject has properties
>> - timestamp (units are DOMHiResTimestamp, http://www.w3.org/TR/hr-time/)
>> - type (name of stats child class, e.g. "OutgoingRTPStream")
>> - id (opaque string)
>>
>> And there are various descendant classes of RTCStatsObject, e.g
>>
>> interface RTCRTPStreamStats : RTCStatsObject {
>>   int ssrc;
>>   StatsObjectID? otherEndStats; // Reference to the stats signalled from our
>> partner.
>> };
>>
>> interface RTCOutgoingRTPStreamStats : RTCRTPStreamStats {
>>   int packetsSent;
>>   long bytesSent;
>> };
>>
>> interface RTCIncomingRTPStreamStats : RTCRTPStreamStats {
>>   int packetsReceived;
>>   long bytesReceived;
>> int packetsLost;
>> };
>>
>> (Names are subject to change)
>>
>> Sample Usage:
>>
>> getStats(null, onStats);
>> onStats = function(report) {
>> for (var id in report) {
>> var obj = report[id];
>> if (obj.type == "RTCIncomingRTPStreamStats") {
>> // print out the number of bytes received on each RTP stream
>> console.log(obj.timestamp + ": ssrc:" + obj.ssrc + " bytes:" +
>> obj.bytesReceived);
>> }
>> }

Received on Friday, 15 February 2013 06:16:13 UTC