- From: Adam Bergkvist <adam.bergkvist@ericsson.com>
- Date: Mon, 24 Jun 2013 08:21:58 +0200
- To: Jim Barnett <Jim.Barnett@genesyslab.com>
- CC: Harald Alvestrand <harald@alvestrand.no>, "public-webrtc@w3.org" <public-webrtc@w3.org>
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 06:22:23 UTC