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

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

From: Harald Alvestrand <harald@alvestrand.no>
Date: Mon, 24 Jun 2013 09:08:46 +0200
Message-ID: <51C7F07E.9070007@alvestrand.no>
To: public-webrtc@w3.org
On 06/24/2013 08:21 AM, Adam Bergkvist wrote:
> 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.

"Closing" has to be a state, because exiting it requires action from a
remote entity. What you're proposing is a set of "states" that are
entered into and exited from by means of local action only; that's unusual.

Usually the thinking is that processing a state transition is protected
by a semaphore; a semaphore is a construct that includes a queue.

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

I think Jim Barnett has it right; the queue we're making explicit is
just the normal way to drive state machines.
Received on Monday, 24 June 2013 07:09:18 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:44 UTC