W3C home > Mailing lists > Public > public-webrtc-logs@w3.org > February 2019

Re: [webrtc-pc] Remove stopped transceivers from getTransceivers() (#2092)

From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
Date: Fri, 15 Feb 2019 16:16:08 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issue_comment.created-464107615-1550247367-sysbot+gh@w3.org>
I think I can finish up this sub-thread here. I was responding to @alvestrand's *"referring to them by list index is foolish"*.

> I think the beauty is that "ontrack" will fire in the same order, not that the index

Same order as what? JS needs a reference. `getTransceivers()` used to be in no order whatsoever. Not sure we want to go back to that. Also, keeping track of track events (no pun intended) is harder in practice than it might seem (e.g. developer: *"Is the first track of the next bunch, or a (potentially new) last track of the previous bunch?"*). Developers would need to keep track of signaling state to separate one group of events from the next. What could go wrong?

For other examples of relying on transceiver order, see [web-platform-tests](https://github.com/web-platform-tests/wpt/blob/master/webrtc/RTCRtpTransceiver.https.html#L1033).

> Removing transceivers does not break this use case.

Agree, just wanted to make sure this didn't devolve into removing transceiver order.

The somewhat related problem is: removing a stopped transceiver other than the last one, changes the indices of all/any transceivers after it by 1, but we already have that problem with `getSenders` and `getReceivers`.

-- 
GitHub Notification of comment by jan-ivar
Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2092#issuecomment-464107615 using your GitHub account
Received on Friday, 15 February 2019 16:16:10 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 4 June 2019 15:32:55 UTC