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

On Feb 19, 2013, at 4:28 PM, Jim Barnett <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.