- From: jan-ivar via GitHub <sysbot+gh@w3.org>
- Date: Wed, 06 Dec 2017 03:02:33 +0000
- To: public-webrtc-logs@w3.org
> I argue that either all operations (addTrack, replaceTrack, removeTrack) should be synchronous I don't think we should entertain any symmetry here. `addTrack` adds a transceiver, `removeTrack` takes a sender as argument, but doesn't undo `addTrack`, and they're both synchronous methods on the pc that fire the negotiationneeded event (on the pc). In contrast, `replaceTrack` is on the sender, asynchronously replaces what's being transmitted before it resolves, and doesn't fire negotiationneeded. > there might be races with what sender.track is when renegotiating? createOffer and createAnswer are [impervious to races](https://w3c.github.io/webrtc-pc/#dfn-final-steps-to-create-an-answer), so I don't see a problem here. As to whether we should rethink the `replaceTrack` API, I'm not hearing any new arguments that weren't discussed [3 years ago](https://lists.w3.org/Archives/Public/public-webrtc/2014Sep/0012.html) when Firefox implemented it. > In the meantime I'm planning on implementing Chrome to do it synchronously That would observably be in violation of the spec, since the spec says `sender.track` must be unchanged when the method returns, so I'm hoping we can avoid that. -- GitHub Notification of comment by jan-ivar Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/1677#issuecomment-349516708 using your GitHub account
Received on Wednesday, 6 December 2017 03:02:36 UTC