Re: Write PeerConnection's operations array as a chain

On 4/29/15 10:44 AM, Harald Alvestrand wrote:
> The chairs seek input on this proposal.
> In particular, I feel that I understand the intent of the original
> language (albeit not what the error handling is), but sentences of the
> form "Let <p> be the result of transforming <operations> by a fulfilment
> handler that runs the following steps" leaves me rather baffled.
> People who feel that they either do or don't understand what this PR is
> intended to accomplish are welcome to comment.

Maybe I should add what it accomplishes.

This PR makes our API deterministic where today it isn't (the problem 
Stefan raised) [1]:

   var senderX = pc.addTrack(trackX);
   var senderY = pc.addTrack(trackY);

   // Will trackY will be in the offer? Sometimes! Non-deterministic!

With this PR, trackX and trackY will always be in the offer. Highly 

This seems like a good thing.

Firefox does this.

.: Jan-Ivar :.


> Comments in the PR.
> Den 24. april 2015 17:03, skrev Jan-Ivar Bruaroey:
>> The spec's "operations array" [1] is under-specified and unconventional
>> by today's standards. Here it is:
>>> ..., for every call to |createOffer|, |setLocalDescription|,
>>> |createAnswer| and |setRemoteDescription|; execute the following steps:
>>> 1.
>>>      Append an object representing the current call being handled (i.e.
>>>      function name and corresponding arguments) to the |operations| array.
>>> 2.
>>>      If the length of the |operations| array is exactly 1, execute the
>>>      function from the front of the queue asynchronously.
>>> 3.
>>>      When the asynchronous operation completes (either successfully or
>>>      with an error), remove the corresponding object from the
>>>      |operations| array. After removal, if the array is non-empty,
>>>      execute the first object queued asynchronously and repeat this
>>>      step on completion.
>>> The general idea is to have only one among |createOffer|,
>>> |setLocalDescription|, |createAnswer| and |setRemoteDescription|
>>> executing at any given time. If subsequent calls are made while one of
>>> them is still executing, they are added to a queue and processed when
>>> the previous operation is fully completed.
>> TL;DR... This is a modest hand-rolled promise chain, defined before
>> promises were common. I propose we modernize the language to take
>> advantage of this well-defined behavior that is available.
>> See PR [2] for language. Firefox release currently implements this PR
>> (see code [3]).
>>> It is valid, and expected, for normal error handling procedures to be
>>> applied.
>> What "normal error handling procedures"? For that matter, what is an
>> "asynchronous operation"? The PR adds standard language to isolate
>> errors from propagating the chain.
>> .: Jan-Ivar :.
>> [1]
>> [2]
>> [3]

Received on Saturday, 2 May 2015 02:48:17 UTC