Re: Question: how should addTrack work in relation to createOffer et. al.?

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). Did anyone 
like what I called AB in a follow-up? 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> 
>