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);
   pc.createOffer();
   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 
deterministic.

This seems like a good thing.

Firefox does this.

.: Jan-Ivar :.

[1] https://lists.w3.org/Archives/Public/public-webrtc/2015Apr/0138.html

> 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] http://w3c.github.io/webrtc-pc/#operation
>> [2] https://github.com/w3c/webrtc-pc/pull/165
>> [3]
>> http://mxr.mozilla.org/mozilla-central/source/dom/media/PeerConnection.js?rev=b11576671375#383

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