- From: jan-ivar via GitHub <sysbot+gh@w3.org>
- Date: Fri, 07 Jul 2017 19:05:57 +0000
- To: public-webrtc-logs@w3.org
The reason to not spec it is we don't want web developers writing *new* code using `addStream`. `addStream` is death to having the right mental model of a peer connection. It's API 101: It hurts comprehension to have [3 competing mental models](https://blog.mozilla.org/webrtc/the-evolution-of-webrtc/) for the same thing when only one is right. Yet `addStream`/`removeStream` is the API of *least resistance* and the *most problems*. The dumb path. Problems: if users add or remove tracks from a stream in any way, it becomes unclear fast what `pc.addStream` and `pc.removeStream` do. Users may leave tracks behind, send bits twice, or have connections not update to changes at all. They'll suffer poor port-reuse, and slow call-setup. Least resistance: MDN's [addStream](https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/addStream) page is a sea of red warnings, yet nobody seems to know or care how `addTrack` and `addTransceiver` work. They're to `addStream` what taking cod liver oil is to soda. Lastly, Firefox is at a disadvantage if people take the dumb path; we don't implement `removeStream`. -- GitHub Notification of comment by jan-ivar Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/1125#issuecomment-313767303 using your GitHub account
Received on Friday, 7 July 2017 19:06:03 UTC