- From: jan-ivar via GitHub <sysbot+gh@w3.org>
- Date: Wed, 07 Jun 2017 02:02:19 +0000
- To: public-webrtc-logs@w3.org
@taylor-b I did some digging, and I need to correct your initial premise: > In the pre-transceiver world, we had addStream/removeStream methods, and "addstream"/"removestream" events. ... Now, we have addTrack/removeTrack... But we only have a single event, "track". So how are applications expected to know when the other peer removed the track? The answer [since Oct 2014](https://github.com/w3c/webrtc-pc/pull/3#issue-45833676) has been *"onremovestream has been removed (now, .onended is fired)."* Transceivers weren't added until [a year later](https://github.com/w3c/webrtc-pc/pull/293), and the "ended" language remains to this day (https://github.com/w3c/webrtc-pc/pull/1168). For a whole year, the spec was `addTrack`/`removeTrack` on one side, and `track` and `ended` on the other, and nothing else. That's the year Firefox [implemented addTrack/removeTrack]( https://hg.mozilla.org/mozilla-central/rev/79525105ef9a). In other words, we did not go straight from streams to transceivers, and the `removestream` event was not removed because of transceivers. It was removed because of `ended`. So we moved from: 1. `addStream`/`removeStream` firing `onaddstream` and `onremovestream` *(Chrome)*, to 2. `addTrack`/`removeTrack` firing `track` and `ended` *(Firefox)*, to 3. `addTransceiver`, and confusion about what happens remotely *(Nobody)*. I cover these 3 stages in my recent [blog post](https://blog.mozilla.org/webrtc/the-evolution-of-webrtc/) and webinar. Also note Chrome fires `track` and `ended` for both `addStream` and `addTrack` through [adapter.js](https://github.com/webrtc/adapter). -- GitHub Notification of comment by jan-ivar Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/1161#issuecomment-306664580 using your GitHub account
Received on Wednesday, 7 June 2017 02:02:25 UTC