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

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.  

- Jim

-----Original Message-----
From: Adam Bergkvist [mailto:adam.bergkvist@ericsson.com] 
Sent: Thursday, June 20, 2013 8:44 AM
To: Harald Alvestrand
Cc: public-webrtc@w3.org
Subject: Re: Operations in invalid states: Exceptions don't make sense.

On 2013-06-20 14:33, Harald Alvestrand wrote:
> On 06/20/2013 10:50 AM, Adam Bergkvist wrote:
>> On 2013-06-19 18:28, Jan-Ivar Bruaroey wrote:
>>> On 6/19/13 2:47 AM, Adam Bergkvist wrote:
>>>> With a processing state, the second call would always fail.
>>>
>>> Agreed.
>>>
>>>> That's deterministic and observable from JS (compared to a queue in 
>>>> the background).
>>>
>>> The current approach is also deterministic, as I showed.
>>> The current approach is also observable from JS because the failure 
>>> callback is called. In fact with Futures/Promises, there's little 
>>> difference.
>>
>> With Future/Promises you practically build the operations queue in 
>> your application; that's rather nice and what I think is desirable.
>
> I think that's hoping for too much.
>
> Using Promises may make it easy to sequence one chain of operations.
> It does not give any protection against (deliberately, maliciously or
> accidentally) firing off multiple chains of operation that happen to 
> interleave.

Sure, I was rather referring to the "easy to chain" properties of Futures/Promises. To protect against, as you call them, multiple chains, that's what a proper state machine is perfect for.

> That's what the queue was supposed to accomplish: Making sure the 
> outcome is deterministic, no matter how stupidly the operations were fired.

Yes, but we can accomplish this without inventing something new.

/Adam

Received on Thursday, 20 June 2013 13:07:18 UTC