- From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
- Date: Mon, 25 Feb 2019 22:41:39 +0000
- To: public-webrtc-logs@w3.org
> > I believe we're consistent: Outstanding Pomises are left pending on `pc.close()`. > RTCRtpSender is not consistently doing that. Sorry, I should have said consistent with the other methods using the [peer connection queue](http://w3c.github.io/webrtc-pc/#enqueue-an-operation). > RTCRtpSender.setParameters and RTCRtpSender.getStats are not checking for stopped/closed before resolving/rejecting the promise. *getStats* is specifically allowed on closed peer connections. *setParameters* is not enqueued, and is not allowed to fail with `InvalidStateError`, so I'd assume it succeeds, which seems benign enough. > Note also that the PR further ties RTCRtpSender with RTCPeerConnection, which is not great. That ship has sailed I think: *replaceTrack* is enqueued on the peer connection queue, for reasons. > It does not align with the idea of being able to create objects like transceivers or data channels directly from an ice connection. You can't do that today. We would need to spec that, but I think we're getting ahead of ourselves. > What is the benefit of the PR vs. removing step 6.4.4.1, or replacing step 6.4.4.1 by rejecting the promise with InvalidStateError? Consistency with the other enqueued methods. Having `transceiver.stop()` cause outstanding *replaceTrack* promises to reject with `InvalidStateError` would be novel. I'm not hearing support for that. -- GitHub Notification of comment by jan-ivar Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2106#issuecomment-467213931 using your GitHub account
Received on Monday, 25 February 2019 22:41:41 UTC