W3C home > Mailing lists > Public > public-webrtc-logs@w3.org > July 2017

Re: [webrtc-pc] Should the spec describe addStream/onaddstream as legacy API?

From: jan-ivar via GitHub <sysbot+gh@w3.org>
Date: Fri, 07 Jul 2017 19:05:57 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issue_comment.created-313767303-1499454355-sysbot+gh@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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:21:40 UTC