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

On 6/18/13 9:15 AM, Adam Bergkvist wrote:
> 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?

I can think of no cases, thankfully. My understanding is that the queue 
is there to make the API deterministic, rather than encourage enqueuing. 
E.g.:

     // Bad code. state=have_local_offer
     pc.setRemoteDescription(answer1, success, mayfail);
     pc.setRemoteDescription(answer2, success, mayfail);

Without a queue, the second call could succeed or fail based on whether 
the first call has completed. With a queue in place it becomes 
deterministic: If call 1 succeeds, then call 2 always fails 
(state=stable). If call 1 fails, then call 2 has the same starting point 
(state=have_local_offer), always.

Why care? Non-deterministic behavior would be bad for 
documentation-reasons alone (having to mention useless edge-cases like 
this).

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

Yes, we could have done that. It would let you throw on bad state, but 
at the cost of doubling the number of states in the state machine. I'm 
not sure it is simpler.

.: Jan-Ivar :.

>
> /Adam B
>

Received on Tuesday, 18 June 2013 21:03:12 UTC