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

On Fri, May 8, 2015 at 2:23 PM, Jan-Ivar Bruaroey <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.


-Ekr


> .: Jan-Ivar :.
>
> [1] https://github.com/w3c/webrtc-pc/pull/165
>
>
>