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

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. 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).

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.

/Adam B

Received on Tuesday, 18 June 2013 13:15:29 UTC