- From: Jan-Ivar Bruaroey <jib@mozilla.com>
- Date: Thu, 18 Dec 2014 15:55:41 -0500
- To: Peter Thatcher <pthatcher@google.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
- CC: Donald Curtis <decurtis@google.com>
- Message-ID: <54933F4D.7020702@mozilla.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