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

On 08/05/15 23:23, Jan-Ivar Bruaroey 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.

Thanks for outlining the options.

I interpreted the conversation as that you and Harald had agreed on B, 
and that is what I meant. That does not seem to be the case :).

I'd be fine with any of the models, I'm just after clarity.

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

Received on Saturday, 9 May 2015 04:46:19 UTC