- 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