- From: Adam Bergkvist <adam.bergkvist@ericsson.com>
- Date: Mon, 24 Jun 2013 10:08:56 +0200
- To: Harald Alvestrand <harald@alvestrand.no>
- CC: public-webrtc@w3.org
On 2013-06-24 09:08, Harald Alvestrand wrote: > 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. An asynchronous operation is asynchronous regardless if it talks to a remote server or does local processing only. > 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. Are there any other Web APIs that lets the API queue up several state changing operations like our queue does? That makes it very hard for the application to check the state and react accordingly, since the state somewhat disconnected from the application. /Adam
Received on Monday, 24 June 2013 08:09:20 UTC