[webrtc-pc] Section 4.3.1

aboba has just created a new issue for https://github.com/w3c/webrtc-pc:

== Section 4.3.1 ==
>From EKR: https://lists.w3.org/Archives/Public/public-webrtc/2017May/0166.html

(operations queue)
This algorith seems to imply that operation is run synchronously
if the queue depth is one (step 6) whereas if it's not, it's run
asynchronously. This definitely isn't invisible in the callback
version (reentrancy) and isn't actually invisible in the promises
version because these operations have side effects. Is it really
the expectation that we should (for instance) start sending
media before the promise resolves? That seems odd.


(setDescription)
The says:
    To set an RTCSessionDescription description on an RTCPeerConnection
    object connection, enqueue the following steps:

    1. Let p be a new promise.

I may be confused, but I don't think that the promise creation and
resolution is in fact queued.

    2. If elements of the SDP were modified, then reject p with a newly
created
    InvalidModificationError and abort these steps.

This only applies to local decriptions.


This algorithm is extremely prescriptive about which error checks
you need to perform and in which order. This is externally observable
because I throw different errors. For instance, why is it the
spec's business whether I check for being in the right state before
or after I check for the SDP being modified.

    5. If the content of description is invalid, then reject p with a
    newly created InvalidAccessError and abort these steps.

What would invalid be here? Anything else?


    2. If description is applied successfully, the user agent must
    queue a task that ru ns the following steps:

Didn't we already queue above?


Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/1277 using your GitHub account

Received on Wednesday, 31 May 2017 16:32:52 UTC