W3C home > Mailing lists > Public > public-webrtc@w3.org > April 2015

Re: onnn is too complex

From: Justin Uberti <juberti@google.com>
Date: Fri, 3 Apr 2015 17:01:50 -0700
Message-ID: <CAOJ7v-2CPYCpymfpi4wOAzgqBRSjGFp0+8dWLQ_4R6TH1RpHuw@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>
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>

> 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 Saturday, 4 April 2015 00:02:37 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:43 UTC