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

Re: Summary of stats discussion in Boston

From: Adam Bergkvist <adam.bergkvist@ericsson.com>
Date: Thu, 14 Feb 2013 08:00:14 +0100
Message-ID: <511C8B7E.5070109@ericsson.com>
To: Martin Thomson <martin.thomson@gmail.com>
CC: Justin Uberti <juberti@google.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
On 2013-02-13 23:31, 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 was just going to write a mail on this topic, as I'm currently putting 
this into the spec, but you beat me to it. :)

I see at least two ways to specify the report object. The way you 
propose with a dedicated interface and a named property getter (1), or 
have it as a regular JavaScript object and describe in prose how it 
should be constructed (2).

I asked this question on the public-script-coord list yesterday [1] and 
it seems like both approaches are fine.

If there was a "(hash)map" counterpart to sequence<T> in WebIDL 
(something like map<KeyT, ValueT>) I think that would be the thing to 
use. The result represented in JavaScript would just be an object in 
that case. The thing that I don't like with (1) is that it introduces a 
new type that doesn't really add much. The only thing that 
differentiates it from any other map-like object, someone else might 
want to specify, is that it may only contain stats objects. I know that 
at least WebKit is moving away from special array-like objects to more 
reusable constructs. I'm not sure it would be right to go to start 
introducing special map-like objects.

What do you browser implementers think about 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.  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.
> 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 Thursday, 14 February 2013 07:00:44 UTC

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