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

Didn't thought about the promise issue, in that case it would be a strange
API. Is the promise necesary in that case? We are only retrieving data, not
processing anything...
El 19/12/2014 08:34, "Peter Thatcher" <pthatcher@google.com> escribió:

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