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

onnn is too complex

From: Martin Thomson <martin.thomson@gmail.com>
Date: Thu, 2 Apr 2015 13:48:03 -0700
Message-ID: <CABkgnnXXpTUry_Jd=hcZ6JzUwq=r+ECL=ZDC834BWzUkbSYYgA@mail.gmail.com>
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

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