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

I think, arguably, PeerConnection.getStats() should continue to return 
all stats, since it's a container for all the other objects. I see scant 
benefit in optimizing away that part.

While it might seem reasonable to use attributes - even for snapshotted 
data - as we break down stats by object, I think it'd be preferable for 
individual objects to return the same syntax as 
PeerConnection.getStats(), otherwise we have same data appearing in 
different forms depending on how it was retrieved.

.: Jan-Ivar :.

On 12/19/14, 10:54 AM, Harald Alvestrand wrote:
> 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).
>>
>>
>


-- 
.: Jan-Ivar :.