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

Re: Summary of stats discussion in Boston

From: Martin Thomson <martin.thomson@gmail.com>
Date: Wed, 13 Feb 2013 17:07:58 -0800
Message-ID: <CABkgnnUjO0MSm-x5vcq0t+UTRdxQyMKCqMQX=2S5LL9ia3JsLA@mail.gmail.com>
To: Justin Uberti <juberti@google.com>
Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>
One last thing.  This was staring me in the face just now:

"""The order that dictionary members are looked up on the ECMAScript
object are not necessarily the same as the object’s property
enumeration order. """

That would seem to indicate that a dictionary is most appropriate.
Unless you felt constrained by the WebIDL for your Java implementation
of RTCPeerConnection.

On 13 February 2013 14:31, Martin Thomson <martin.thomson@gmail.com> 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".
>
> 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 01:08:27 UTC

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