- From: Justin Uberti <juberti@google.com>
- Date: Wed, 29 Apr 2015 21:52:38 -0700
- To: Jan-Ivar Bruaroey <jib@mozilla.com>
- Cc: Stefan HÃ¥kansson LK <stefan.lk.hakansson@ericsson.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
- Message-ID: <CAOJ7v-1FtOtk7G_krhruDn4BZGkbFBBStCzOX2gr=LBCL+Ktaw@mail.gmail.com>
Obviously I prefer a deterministic outcome. But I think it would be better to not include trackY in the createOffer output - it seems unintuitive. On Fri, Apr 24, 2015 at 8:38 AM, Jan-Ivar Bruaroey <jib@mozilla.com> wrote: > On 4/23/15 8:34 AM, Stefan HÃ¥kansson LK wrote: > > The current spec is pretty clear on how addTrack works in isolation: > > a RTPSender is synchronously returned. > > However, how addTrack relates to related (enqueued) operations is less > clear. > > As an example, for the sequence > > var senderX = pc.addTrack(trackX); > pc.createOffer(); > var senderY = pc.addTrack(trackY); > > 1. would track/senderY be represented in the offer in any case? > 2. if so, would it be consistently represented in the offer or would it > depend on e.g. queue status? > > > Sadly, I think this is nondeterministic today because of how our > operations array is defined [1]: "If the length of the operations array > is exactly 1, execute the function from the front of the queue > asynchronously." > > > Meaning the outcome can vary from run to run. > > One way to spec this would be to say that createOffer takes a snapshot > of the current senders when called, and changes between that snapshot > and the actual execution of createOffer are not taken into account. > > > Since JavaScript is a run-to-completion language, another (common?) > approach would be to queue a (micro) task to execute the asynchronous > operation, as I've just proposed today here in another thread. > > Not only would this unify behavior between when something is on the queue > vs. when nothing is on the queue, but it would make the following > deterministic: > > var senderX = pc.addTrack(trackX); > pc.createOffer(); > var senderY = pc.addTrack(trackY); > // Both trackX and trackY will always be in the offer. > > > No copying of state needed. > > Is this the way we should go? > > (This relates to github Issue #156 for webrtc) > > Stefan > > > .: Jan-Ivar :. > > [1] http://w3c.github.io/webrtc-pc/#operation > >
Received on Thursday, 30 April 2015 04:53:26 UTC