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

Yes, but are you going to signal an error if the developer makes a call when you're in a processing state?  In that case, you'll end up with a lot of polling code, sitting  around waiting for the state to change.  That's an ugly programming model.  Now if it's the case that some operations can succeed when you're in the processing state, then that's a good argument for having a processing state, since  it now behaves like a first-class state, with a differentiated response to different events.  But if all operations are going to fail until the processing is done, the queuing model is cleaner.

- Jim

-----Original Message-----
From: Adam Bergkvist [mailto:adam.bergkvist@ericsson.com] 
Sent: Monday, June 24, 2013 2:22 AM
To: Jim Barnett
Cc: Harald Alvestrand; public-webrtc@w3.org
Subject: Re: Operations in invalid states: Exceptions don't make sense.

On 2013-06-20 15:06, Jim Barnett wrote:
> A background event queue is one of the basic concepts of state 
> machines.  Take a look at scxml http://www.w3.org/TR/scxml/, which is 
> based on Harel State charts (and UML state machines):
> http://www.wisdom.weizmann.ac.il/~dharel/reactive_systems.html
>
> The standard model for a state machine is that it maintains an event 
> queue.  It doesn't pull the next event off the queue until it finishes 
> processing the first. There is no intermediate "I am processing an 
> event" state.
>

There are several examples of Web APIs that enters processing states to protect the object from being manipulated at some time. For example, when a WebSocket starts the closing handshake, it enters the "closing" 
state.

I don't think our case is any different. We want to protect the local and remote descriptions from being manipulated when another operation is ongoing. Representing that with a state lets the developer know what state the PeerConnection is in at every call to any of PeerConnection's methods.

/Adam

Received on Monday, 24 June 2013 11:44:40 UTC