Re: [webrtc-stats] Rename sender/receiver/track dictionaries

We needed a name that could mean "Sender or Receiver" for dictionaries with members in common for both senders and receivers; "Handler" because it's more concise than "SenderOrReceiver" (and we can't use a name like "Transceiver" because that already has special meaning and implies "SenderAndReceiver").

We collect stats for what we have. We have senders, receivers and RTP streams. Tracks are the _biproduct_ of this machinery. Not the other way around.

"Track" stats sounds intuitive until you realize these are just a snapshot of sender stats. The current definitions describe a hierarchy in terms of tracks, e.g:
```
RTCMediaStreamTrackStats
RTCVideoStreamTrackStats
RTCVideoSenderStats
RTCLocalVideoStreamTrackStats
```
This is completely backwards. It does not represent the components that the stats are collected from and make it seem like senders are the biproduct of tracks.

I would argue that "track" stats can be deprecated in favor of "sender" stats and that this legacy view of the components should go away. "Sender" is more future-proof than "track" stats.

That said I agree there is utility in true track stats, since often it is this biproduct you are interested in - e.g. What framerate am I getting on this current setup of the machinery? On this _track_?
But stats belonging to tracks should be added to the track dictionary, which is at the bottom of the hierarchy (if we have a hierarchy that represents how this actually works and not the other way around). The current naming scheme would have you believe that track members should be added high up in the hierarchy - this is wrong and would pollute the sender/receiver stats.

Is there something I need to clarify? @alvestrand what's your take?

-- 
GitHub Notification of comment by henbos
Please view or discuss this issue at https://github.com/w3c/webrtc-stats/pull/322#issuecomment-364867968 using your GitHub account

Received on Monday, 12 February 2018 09:25:46 UTC