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

On 2013-06-18 23:02, Jan-Ivar Bruaroey wrote:
> 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.:

Thank you for clarifying this. But is this new approach any easier than 
classical states?

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

With a processing state, the second call would always fail. That's 
deterministic and observable from JS (compared to a queue in the 
background).

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

A single processing state would be enough to start with, and it could be 
expanded if developers asked for more.

/Adam

Received on Wednesday, 19 June 2013 06:47:46 UTC