- From: Jan-Ivar Bruaroey <jib@mozilla.com>
- Date: Fri, 19 Dec 2014 11:26:15 -0500
- To: Harald Alvestrand <harald@alvestrand.no>, public-webrtc@w3.org
- Message-ID: <549451A7.3040508@mozilla.com>
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 :.
Received on Friday, 19 December 2014 16:26:43 UTC