- From: Adam Roach <adam@nostrum.com>
- Date: Wed, 22 May 2013 15:31:45 +0800
- To: "public-webrtc@w3.org" <public-webrtc@w3.org>
- Message-ID: <519C7461.60000@nostrum.com>
Currently, the WebRTC spec has some implication that a PeerConnection's
signalingState should be checked at the time an operation (e.g.,
setRemoteDescription) is enqueued, and an that an exception should be
thrown if the state is not appropriate for the indicated operation /at
that time//,/ regardless of how the already-enqueued operations may
change that state.
This is covered in section 4.6.1 (Error Handling / General Principles):
" An exception /MUST/ be thrown... [if a] function call was made when
the RTCPeerConnection is in an invalid state, or a state in which that
particular function is not allowed to be executed."
This interacts badly with the conceptual model that we currently have
around operations, which is that scripts are allowed to make several
calls on the PeerConnection without first waiting for the prior one to
complete (with the result being that the PeerConnection queues such
operations until the previous one completes).
Roughly speaking, this means that the PC state can be okay at the time
an operation is enqueued, but invalid by the time the operation is
executed. Conversely, the PC state may be invalid at the time an
operation is attempted, but be changed to an invalid state by the time
the operation is to be run.
The first set of circumstances requires us to allow async error
callbacks for invalid states.
The second set of circumstances means that synchronous checks will,
under some circumstances, throw exceptions when it is inappropriate to
do so.
In other words, I think this points to an absolute requirement to check
states async and an absolute prohibition on checking them synchronously.
The specific change I'm requesting is:
* Remove the second bullet from section 4.6.1
* Change step 1 of "addStream" in section 4.3.2.2 to end with
"...abort these steps, and call the addStream error callback with an
RTCError of INVALID_STATE"
* Remove step 1 from "close" in section 4.3.2.2
* Change step 2 of "addStream" in section 4.3.2.2 to end with
"...abort these steps, and call the removeStream error callback with
an RTCError of INVALID_STATE"
* Change the first bullet of "setLocalDescription" in section 4.3.2.2
to end with "...abort these steps, and call the setLocalDescription
error callback with an RTCError of INVALID_STATE"
* Change step 1 of section 5.1.2 to end with "...call the
createDataChannel error callback with an RTCError of INVALID_STATE."
* Remove step 2 from section 5.2.3 (for this reason and for the reason
that readyState no longer exists)
* Change step 1 of section 7.2.1 to end with "...call the getStats
error callback with an RTCError of INVALID_STATE."
* Change step 1 of section 8.2.2, setIdentityProvider to end with
"...abort these steps, and call the setIdentityProvider error
callback with an RTCError of INVALID_STATE"
/a
Received on Wednesday, 22 May 2013 07:32:22 UTC