- From: Sergio Garcia Murillo via GitHub <sysbot+gh@w3.org>
- Date: Fri, 02 Feb 2018 09:25:25 +0000
- To: public-webrtc-logs@w3.org
I agree, if there is not a big technical issue we have to resolve or all browser implementators decide it is just too difficult to implement and support both models I think we are too late in the process to make such a big change. I am all in for cleaner APIs, but then I would get rid of peerconnection and transceivers altogether. Which by the way IMHO should be the scope of next webrtc chapter. Regards Sergio On 02/02/2018 10:17, Philipp Hancke wrote: > > So we got rid of the legacy streams API without specifiyng them. > Philosophically that is bad but nobody volunteered to write the spec. > It is very clear for developers that addStream is the legacy API. > > addTrack/removeTrack is confusing because it is supported both in the > "track-based" API (shipped in Firefox and recently Chrome) and the > transceiver model (in FF59). And they behave /very/ different in both > models which creates a lot of confusion. > > I dislike addTransceiver because it is much easier to explain a web > developer > > * "you take your stream from getUserMedia and add the stream to the > peerconnection" or > * "you take your stream from getUserMedia and add all the tracks to > the peerconnection" > than to explain what a transceiver is. > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub > <https://github.com/w3c/webrtc-pc/issues/1758#issuecomment-362530492>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/ABBW8yo8OKA44nVAc9WmAv-AKnf2o4g9ks5tQtKggaJpZM4R2DVK>. > -- GitHub Notification of comment by murillo128 Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/1758#issuecomment-362532416 using your GitHub account
Received on Friday, 2 February 2018 09:25:31 UTC