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

On Thu, Dec 18, 2014 at 12:55 PM, Jan-Ivar Bruaroey <jib@mozilla.com> wrote:
>
>  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 ();
> }
>

​Right.
​


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

​I think you're right about retiring the selector and moving track-specific
stats to RtpSender.getStats() and RtpReceiver.getStats().​
​



>
>
>   Has there already been discussion about this that I don't remember?
>
>
> .: Jan-Ivar :.
>
>