RE: On <scxml> not being a <state>

Gavin,
If I understand your use case correctly,  you want the state machine to wait in a certain state for a system init event, and then take one of several transitions conditioned by data in the event.   One of the possible transitions would restore a previous state of the system.  If that understanding is correct, then I think something like <anchor> is what you want, particularly if you want to roll back the datamodel as well.  You would place anchors at each point you might want to roll back to (e.g. "initPhase1,  initPhase2,  readyToDoFoo, doneWithFoo...) and then target each of them with one of the transitions.  When the system init event comes, you decide which transition to take.  Is this what you want?

On a couple of other tangentially related issues:

1.)    Implementations can store off the state of a machine and rehydrate it later without any changes to the spec.  (There's nothing in the spec that requires the machine to remain in memory all the time.)   If you know that the machine is going to be sitting there for a while, you can write out its state to a DB, free up the resources it is using, and then restore its state and resuming running at a later point.  As long as you restore the exact state configuration, datamodel, etc., this doesn't affect the semantics at all.  (Genesys does this all the time.)

2.)    That said, it might be  useful  for a future version of the spec to give the environment the ability to choose the initial state configuration dynamically at start up time, along the lines that I indicated in my last email.  If we did this, we would make sure that all intermediate states were properly entered (with their onentry firing, etc.)  We do this now with <scxml>'s 'initial' attribute, which can point to states deep inside the state machine.   When this happens, all their ancestors are entered in the appropriate order.  All the future version of the spec would do would be to give the environment the ability to override <scxml>'s initial attribute, just as it can currently override the initial values of <data> elements.

-          Jim

From: Gavin Kistner [mailto:phrogz@me.com]
Sent: Tuesday, February 19, 2013 10:47 PM
To: Jim Barnett
Cc: www-voice@w3.org
Subject: Re: On <scxml> not being a <state>

On Feb 19, 2013, at 4:28 PM, Jim Barnett <Jim.Barnett@genesyslab.com<mailto:Jim.Barnett@genesyslab.com>> wrote:
"The Platform _must_ provide a way for the environment to specify the initial state configuration and state of the datamodel.   Such a specification _must_ take precedence over the value of <scxml>'s initial attribute"

FWIW it is important for my application to ensure that the states are actually entered (and not just teleported into the configuration) because I rely on certain callback events exposed by the interpreter as states are entered/exited.


For the time being, though, since you need a specified location to re-write, why not use <scxml>'s 'intial' attribute?  It can take multiple values, so it should work just as well as history.

I need to not immediately boot into the restored state. I need to be in a "splash screen" state while certain boot-up procedures happen. Only once all is ready does my application inject a system.initialized event into the system, and then one of multiple transitions responding to that event _might_ cause the state to be restored (depending on which conditional transition is taken).


Neither 'initial' nor <history> will restore the previous values of the datamodel, though.  That's why I thought something like <anchor>, which snapshots the datamodel, might be of interest.

A good point to keep in mind. In my case most of the application data is stored outside the state machine data model, and this data (and the data model) are both restored appropriately during startup.