[webrtc-pc] pc.addTrack/removeTrack are confusing and mostly redundant. Mark as legacy?

jan-ivar has just created a new issue for https://github.com/w3c/webrtc-pc:

== pc.addTrack/removeTrack are confusing and mostly redundant. Mark as legacy? ==
In APIs in general we want to avoid competing mental models at all cost. We have (had) [three](https://blog.mozilla.org/webrtc/the-evolution-of-webrtc/).

`addTrack`/`removeTrack` are mostly redundant *stage 2* leaky abstractions with false symmetry. They're no longer the right abstraction to view the design through, causing [confusion](https://github.com/w3c/webrtc-pc/issues/1756).

I'm not suggesting we remove them from the spec, but that we move them to a legacy section to avoid people being confused by them when looking for things that inform the design.

#### Why they're confusing

What they have in common with `addStream`/`removeStream` is that:
 1. They never quite fit, and were an iteration toward the `addTransceiver` API.
 2. If you try to understand WebRTC through them, you end up with the wrong model in your head.

Consider how poorly their names match what they do now:
 1. `pc.addTrack(track, stream)` adds a *transceiver* (or piggybacks on one from SRD).
 2. `pc.removeTrack(sender)` is a setter for `sender.track` (to `null`) and `sender.direction`.

Naively, one would expect one to undo the other, but this is wholly untrue. This makes them poor APIs.

#### Why they're redundant

Modern equivalents exist: `pc.addTransceiver(track, {streams})`, `sender.direction = newdir` and `await sender.replaceTrack(track)`. Though beware they don't work exactly the same in edge-cases.

Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/1758 using your GitHub account

Received on Thursday, 1 February 2018 18:11:44 UTC