- From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
- Date: Thu, 30 Apr 2015 06:42:54 +0000
- To: Jan-Ivar Bruaroey <jib@mozilla.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
On 24/04/15 17:38, Jan-Ivar Bruaroey 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. How does that work? And what determines if trackY is represented in the offer or not (in the example it is added right after createOffer is called, but there can be many scenarios here, like a bit later or in another context)? > > 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 06:43:21 UTC