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

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