Re: Write PeerConnection's operations array as a chain

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.

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 Wednesday, 29 April 2015 14:44:59 UTC