W3C home > Mailing lists > Public > public-webrtc@w3.org > December 2014

Re: per-DataChannel stats: on PeerConnection or on DataChannel?

From: Jan-Ivar Bruaroey <jib@mozilla.com>
Date: Thu, 18 Dec 2014 15:55:41 -0500
Message-ID: <54933F4D.7020702@mozilla.com>
To: Peter Thatcher <pthatcher@google.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
CC: Donald Curtis <decurtis@google.com>
On 12/18/14, 3:20 PM, Peter Thatcher wrote:
> ​In the current WebRTC draft, we have:
>
> partial interface RTCPeerConnection {
>     void getStats (MediaStreamTrack? selector, RTCStatsCallback 
> successCallback, RTCPeerConnectionErrorCallback failureCallback);
> }
>
> To add the ability to get stats about a particular RTCDataChannel do 
> we want to have
>
> A.  ​PeerConnection.getStats(RTCDataChannel, ..., ...), like so:
>
> partial interface RTCPeerConnection {
>     void getStats (RTCDataChannel? selector, RTCStatsCallback 
> successCallback, RTCPeerConnectionErrorCallback failureCallback);
> }

Nit: I don't think an overload works with a nullable argument since the 
binding code wont know which method to call when null is provided, so 
we'd probably need to merge them:

     Promise<RTCStatsReport> getStats ((MediaStreamTrack or 
RTCDataChannel)? selector));

> or
>
> B.  RTCDataChannel.getStats(..., ...) like so:
>
> partial interface RTCDataChannel {
>     void getStats (RTCStatsCallback successCallback, 
> RTCPeerConnectionErrorCallback failureCallback);
> }
>
> I prefer B.  LIkewise, I think it makes sense to eventually have 
> RtpSender.getStats, DtlsTransport.getStats, and IceTransport.getStats.

Presuming you mean:

partial interface RTCDataChannel {
     Promise<RTCStatsReport> getStats ();
}

then I agree. The getStats API was designed before the proliferation of 
sub-objects like RtpSender etc. so this seems like the proper evolution.

> That way, the browser doesn't have to gather stats about everything to 
> get stats about something, and we don't have to add a new 
> PeerConnection.getStats overload for every single new object we add.

I don't think approach A would gather stats about everything either 
provided a selector, but I still agree B seems better. In fact, we 
should probably retire the selector argument on PeerConnection.getStats 
now, given the direction we seem to be going in.

> Has there already been discussion about this that I don't remember?

.: Jan-Ivar :.
Received on Thursday, 18 December 2014 20:56:10 UTC

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