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

A property that returns a promise?  Are there such things?

On Thu, Dec 18, 2014 at 11:29 PM, piranna@gmail.com <piranna@gmail.com>
wrote:
>
> Moving getStats() to a per-class method, it should be a read-only property
> instead of a getter.
> El 19/12/2014 07:32, "Stefan Håkansson LK" <
> stefan.lk.hakansson@ericsson.com> escribió:
>
> On 18/12/14 21:57, Jan-Ivar Bruaroey wrote:
>> > On 12/18/14, 3:20 PM, Peter Thatcher wrote:
>> >>
>> >> 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.
>>
>> I also think this is the natural way to do it (and presumably we should
>> have stats on RtpReceiver as well to maintain the possibility to get
>> stats for received tracks).
>>
>> However, I've not thought through what it would mean in terms of
>> document structure (now that we've moved definition of _what_ stats to
>> report into a separate document).
>>
>>
>>

Received on Friday, 19 December 2014 07:34:37 UTC