Re: onnn is too complex

I'm not sure I follow exactly which part of the text you are concerned
about. Is it the firing details in 4.8.3?

On Thu, Apr 2, 2015 at 1:48 PM, Martin Thomson <martin.thomson@gmail.com>
wrote:

> 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).
>
>