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

On 05/04/2015 05:23 PM, Jan-Ivar Bruaroey wrote:
> On 5/4/15 2:39 AM, Stefan Håkansson LK wrote:
>> On 03/05/15 22:55, Harald Alvestrand wrote:
>>> On 05/03/2015 08:41 PM, Stefan Håkansson LK wrote:
>>>> On 03/05/15 18:07, Harald Alvestrand wrote:
>>>>> This means to me that Jan-Ivar's resolution can be correct unless we
>>>>> change addTrack.
>>> Ouch. I misread this part. We are changing the tracks structure outside
>>> the operations queue by AddTrack.
>>>
>>> I think that's a mistake, but I can't argue that it's not in the 
>>> spec :-(
>
> Care to argue for why you think it is a mistake, to allow for a 
> discussion that leads to a joint understanding of the issue?
:-)

Because it leads to exactly the behavior you outlined in your analysis: 
The user does a set of operations in a certain sequence; the result of 
the operation has some of the operations the user thinks of as "earlier" 
being affected by some of the operations the user thinks of as "later".

Furthermore, as soon as the sequence of operations gets broken up by 
visits to the event loop, it goes back to being nondeterministic:

addTrack(X); createOffer(); addTrack(Y) is deterministic (but surprising).
addTrack(X); createOffer(); 
irrelevant-promise-returning-operation().then(s => addTrack(Y)) is 
non-deterministic. (apologies if I miswrote the => syntax).

I think it violates the principle of "don't surprise the user if you 
don't have to".

Arguing against my own point: Adding X and thereafter inspecting the PC 
and not finding X is also surprising, so perhaps it is the question of 
which is the least objectionable surprise.

>
>> Perhaps add/removeTrack should be part of the same queue.
>
> Perhaps not.
>
>> (I was thinking about a more radical proposal: remove the queue and
>> force the application to wait for promises to resolve before moving on.
>
> What problem do you attribute to the existence of the queue exactly?
>
>> THis would be more in line with the vein of JSEP ("move the state
>> handling to the app") IMO. But I think there are cases that makes this a
>> bad idea.)
>
> I think at this point we should demand reasons for why a change should 
> be considered, before looking for reasons not to.

Can't parse that sentence....

>
> .: Jan-Ivar :.
>

Received on Monday, 4 May 2015 15:47:49 UTC