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

On 12/19/2014 08:37 AM, piranna@gmail.com wrote:
>
> 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...
>

We're returning snapshots of data as they were at a given time (that's 
why each component of the stats structure has its own timestamp).

Sometimes the most recent data isn't on the currently executing process 
- and feeding a stream of data across process boundaries just in case 
someone eventually wants to do getStats on them is an expensive process 
- perhaps prohibitively so.

Trying to get data synchronously would severely constrain the ways in 
which getStats can be implemented.






> El 19/12/2014 08:34, "Peter Thatcher" <pthatcher@google.com 
> <mailto: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
>     <mailto:piranna@gmail.com> <piranna@gmail.com
>     <mailto: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
>         <mailto: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).
>
>