Re: Alternatives to GetDeletedStats()

Hi Harald, Jan-Ivar,

I missed this discussion at the last interim, so find it surprising that
the in issue #235 was the memory problem and the proposal was to not keep
old stats around.

Going through the slide-proposal, it seems the browser would still need to
store the stats albeit in two different dictionaries... So is speed really
a problem because the finalized stats are anyway not changing?

Regards,
Varun





On Wed, Jan 17, 2018 at 12:07 PM, Harald Alvestrand <harald@alvestrand.no>
wrote:

> In the last WebRTC VI (slides at
> https://www.w3.org/2011/04/webrtc/wiki/images/6/68/WebRTCWG-2018-01-11.pdf
> ),
> Jan-Ivar presented a proposal for handling stats for deleted/removed
> objects that looked like this:
>
>
> partial interface RTCPeerConnection {
>   RTCStatsReport getCompletedStats(optional MediaStreamTrack? selector =
> null);
> };
>
> I've been pondering other options, and came up with one:
>
> partial interface RTCPeerConnection {
>    attribute EventHandler onstatsobjectended;
> }
>
> and an event
>
> interface RTCStatsEvent : Event {
>    readonly attribute RTCStats finalStats;
> }
>
>
> The advantage of this is that as long as there's no listener attached,
> this produces no overhead that grows over time; when there's a listener
> attached, the memory and time overhead is the caller's problem.
>
> It's trivial to shim getCompletedStats on top of this:
>
> pc.onstatsobjectended = function(e) {
>    pc._completedStats.pushBack(e.finalStats);
> }
>
> pc.prototype.getCompletedStats = function() {
>    return pc._completedStats;
> }
>
> The same thing can be added to RTPSender and RTPReceiver, of course.
>
> Thoughts? Is this simpler than getCompletedStats? Are there huge
> disadvantages to this approach?
>
> Harald
>
>
>
>


-- 
Founder, CEO, callstats.io
http://www.callstats.io

Interested in networking, media quality, and diagnostics.
We are hiring!: www.callstats.io/jobs/