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

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

From: Adam Bergkvist <adam.bergkvist@ericsson.com>
Date: Wed, 19 Jun 2013 08:47:21 +0200
Message-ID: <51C153F9.8010907@ericsson.com>
To: Jan-Ivar Bruaroey <jib@mozilla.com>
CC: public-webrtc@w3.org
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 

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

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

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