W3C home > Mailing lists > Public > public-webrtc@w3.org > May 2013

Operations in invalid states: Exceptions don't make sense.

From: Adam Roach <adam@nostrum.com>
Date: Wed, 22 May 2013 15:31:45 +0800
Message-ID: <519C7461.60000@nostrum.com>
To: "public-webrtc@w3.org" <public-webrtc@w3.org>
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

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:33 UTC