- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Thu, 2 Apr 2015 13:48:03 -0700
- To: "public-webrtc@w3.org" <public-webrtc@w3.org>
https://w3c.github.io/webrtc-pc/#session-negotiation-model Just looking at this (we have a small bug here), I notice that the behaviour needed to accommodate the synchronous codepath without generating the event is busted. Mostly, I think that this is excessively byzantine, but I can concede that this might be considered a matter of taste. The bug, however, suggests that attempting this sort of irregular practice was simply unwise. I would like to request that we not try to be clever like this: if an event needs to be fired, fire it. Ostensibly, we have this complexity to support this case: pc.addTrack(t); pc.createOffer() .then(o => pc.setLocalDescription(o)); ...all without firing onnegotiationneeded ever. In practice, I don't think that this works. For one, it's unclear *which* queue the onnn checking is performed on. Assuming that it is the DOM queue (in the sense of the DOM *queue a task*), then the event might be fired anyway, because addTrack call finishes prior to the call to createOffer. That will depend on implementation details, because there might be a few intermediate dispatches for miscellaneous accounting purposes between addTrack and createOffer. Firefox has a couple, which would allow the onnn task plenty of time to get time to execute and fire. If this is instead the RTCPeerConnection task queue, then it still won't work because the task still arrives before we get to setLocalDescription, again, though the if the scheduling setup is such that promise continuations are allowed to jump the queue, maybe not. This could be much simpler. If (trigger conditions for onnnegotiationneeded are met): if (stable): fire the event in the normal fashion, no tricks else: set a flag (and fire it later) This is what we have implemented in Firefox (modulo aforementioned bug).
Received on Thursday, 2 April 2015 20:48:30 UTC