- From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
- Date: Wed, 13 May 2015 13:17:26 +0000
- To: Jan-Ivar Bruaroey <jib@mozilla.com>, Eric Rescorla <ekr@rtfm.com>
- CC: Harald Alvestrand <harald@alvestrand.no>, "public-webrtc@w3.org" <public-webrtc@w3.org>
On 12/05/15 13:49, Jan-Ivar Bruaroey wrote: > On 5/12/15 12:50 AM, Eric Rescorla wrote: >> On Fri, May 8, 2015 at 2:23 PM, Jan-Ivar Bruaroey <jib@mozilla.com >> <mailto:jib@mozilla.com>> wrote: >> >> 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. >> >> >> I would not be in favor of A or C. If I understand B correctly, that's >> the correct behavior. > > I'm OK with B, though I wonder how much state needs to be queued > (obivously not the signaling-state, the reason for queuing). Yes, that is an issue. I guess you need to queue all current senders (including their internal settings). > Did anyone > like what I called AB in a follow-up? I read it, but got confused at the point when you said you were torn. It seemed to me that you then presented two options, but never said which one you are for. Up to that point your reasoning seem OK to me. > I think that gives the same > behavior as B in the regular (non-queued) case, with fewer changes to > the spec. > > .: Jan-Ivar :. > >> -Ekr >> >> .: Jan-Ivar :. >> >> [1] https://github.com/w3c/webrtc-pc/pull/16 >> <https://github.com/w3c/webrtc-pc/pull/165> >>
Received on Wednesday, 13 May 2015 13:17:56 UTC