- From: Jan-Ivar Bruaroey <jib@mozilla.com>
- Date: Fri, 08 May 2015 17:23:48 -0400
- To: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>, Harald Alvestrand <harald@alvestrand.no>, "public-webrtc@w3.org" <public-webrtc@w3.org>
On 5/8/15 9:43 AM, Stefan Håkansson LK wrote: > Trying to summarize this discussion: > > It seems that there is agreement: > > * the offer created by createOffer will only take into account the > senders (and their respective settings) that exist at the time when > createOffer is called - anything that happens after will not be reflected > > Is this right? Not quite I fear. Depends on your definition of "the time when createOffer is called". Lets call this A: Since createOffer is queued in the operations chain, what I realized in this thread, and agree is needed at a minimum, is that, to avoid non-determinism, createOffer must take into account the senders that exist at the time when it comes off the queue and is executed, rather than any time later. This would simply require wording under createOffer, ideally as steps in a processing model, which is sorely needed anyways. It would not require createOffer-specific changes to the description of the operations chain. It would not change much else, which means it still requires accepting PR 222 to fix the "sometimes y is added, sometimes it is not" surprise. E.g. for pc.addTrack(X); pc.createOffer(); pc.addTrack(Y) the offer would always contain X and Y (regardless of what's on the queue). I agree with Martin where he says [1]: "One thing that I like about this is that it removes the synchronous step. Having a function run synchronously or asynchronously depending on something that has happened elsewhere is a very good way to ensure that surprises happen. Allowing the current execution context to run to completion before executing any potentially asynchronous operation is always better than having surprises." (Martin, sorry for quoting you here, but I thought it was a good point that got lost in the older PR [1]). I could see us doing this. I suspect it is not what you meant. Lets call this B: I think what you mean is have createOffer take into account the senders that exist at the time when the content JS calls createOffer. The only benefit I see to this (and correct me if I'm wrong) would be to try to have the offer never contain Y in the common (not queued) case, and ignore the non-common (queued) case, since essentially "people, quit doing that!" It seems to me this would require createOffer-specific changes to the description of the operations chain (not to mention the other methods we haven't talked about). And you still have the "sometimes y is added, sometimes it is not" surprise. You would therefore not want PR 222 here. Lets call this C: Same as B, plus rip out the operations queue, and have methods throw if called at the wrong time. This removes the need for the queue and solves the "offer never contains Y" problem that way. I think I like A and C the best. .: Jan-Ivar :. [1] https://github.com/w3c/webrtc-pc/pull/165
Received on Friday, 8 May 2015 21:24:20 UTC