[Interest] serialization of QStateMachine for recovery mode

[Wegner]

Hi Mandeep and K.Frank!
...
>> Let's take a over-simplified SM.
>>
>> A->B->C->D
>>
>> now if the app crashed while it was state C, on restarting the app, I don't
>> see a legal way of directly taking the SM to C, other than replaying the
>> events that caused transitions to it.
>>
>> Or is there some other trick to it?
>
> First, I won't speak to the details of the Qt state-machine
> implementation (because I don't really know them).

Ok, sure we can implement it on our own but still the question is if QSM 
can assist here. But lets keep it general for now.

> I wouldn't call it a trick.
> It's reasonable to imagine that your state-machine framework
> can do something (or can be modified to do something) like
> this:
>
>     myStateMachine.state = stateC;

In general such a call would be against any finite state machine 
structure, right? For safety I would set this method as a very rare used 
friend method in order to prevent misuse.


> So, schematically, your code might look something like this:
>
>     if (normalMode) {
>        startEventLoop();
>     }
>     else if (recoveryMode) {
>        myStateMachine.state = stateC;
>        startEventLoop();
>     }
>
> If your state-machine framework won't let you do this, or if you
> prefer to live within the formal approach of events and transitions,
> then you could add some helper events and transitions to your
> state machine.  Let's say that your state machine gets initialized
> to startState.  Then you could add:
>
>        event      transition
>
>        goToA:   startState --> stateA
>        goToB:   startState --> stateB
>        goToC:   startState --> stateC
>        goToD:   startState --> stateD
>
> Then at startup, if you're in recovery mode, you would do
> something like;
>
>     myStateMachine.postEvent (goToC);
>
> (But I would probably consider this overkill, and just
> implement making "myStateMachine.state = stateC;"
> work.)

Well, in general I would consider working with this approach and 
automatically adding those transitions between the start state and all 
other states. QTransition could be derived to QRecoveryTransition that 
throws only if a QRecoveryEvent is posted.
But then we would need to keep some kind of a reference to the current 
state within the state machine. And I saw no opportunity to address the 
current state in QSM. Automatically adding a unique ID might help here...

But as my intention is to use this approach in a work flow driven 
application that takes care of building up a set of data I also will 
have to take care of keeping data and state machine consistent.
If some data would be lost but the state machine is recovered to a later 
state then we would end up in an inconsistent state! So recovering any 
state without check of data is critical.

So my current approach is to recover the data and set up a special 
QRecoveryState/-Transition connection with guards on data elements that 
once an QRecoveryEvent is posted automatically goes all the way to the 
right state.

Would that be a considerable approach?

Great discussion!

Best Regards,
Ingmar