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

On 2013-06-18 15:49, Eric Rescorla wrote:
>
>
>
> On Tue, Jun 18, 2013 at 6:15 AM, Adam Bergkvist
> <adam.bergkvist@ericsson.com <mailto:adam.bergkvist@ericsson.com>> wrote:
>
>     On 2013-05-22 09:31, Adam Roach wrote:
>
>         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).
>
>
>     I'm currently editing the spec based on the discussion in this
>     thread but everything isn't really clear to me.
>
>     It makes sense to only allow one operation that affects or is
>     dependent on the PeerConnection's signaling state at a time, but can
>     you provide an example where it's useful to queue up several calls
>     on a PeerConnection without waiting for the success callback of the
>     previous call? It's a high risk that such code is error prone.
>
>
> Given that the calls are asynchronous, I don't see how we can stop people.
>

We can't, but we can make errors more predictable. With state checking, 
a function called in a bad state always fails (throws). With a queue, it 
dependson what's on the queue before the operation is picked up; the 
operation might succeed or fail.

>     It also involves a lot of state checking on the thread that
>     processes the queued operations which is not the JS thread (unless I
>     misunderstood).
>
>
> That has to happen anyway. In fact, it's that that this API is trying to
> accomodate.

It's different. With a queue, the operation is put on the queue and the 
thread that processes the queue needs to query the state when a 
particular operation is picked up.

With states in JS, the PeerConnection has a state when the operation is 
sent to the webrtc thread at it won't change until the webrtc thread 
schedules a task to report the result and set the new desired state.

>
>     Wouldn't it be simpler to have a model where the PeerConnection
>     enters a "processing" state when, for example, setLocalDescription()
>     is called, and the state is updated in the task that fires the
>     methods success or error callback? The "single operation at a time"
>     rule would then be enforced by the PeerConnection signaling state.
>
> That actually sounds quite confusing.

I think it's more aligned with how other APIs work. See WebSocket's 
CONNECTING and CLOSING states. These are observable from the 
application, a queue in the backend is not.

/Adam

Received on Wednesday, 19 June 2013 06:33:15 UTC