Theoretical questions

[EduardShaid]

I have purely theoretical questions that you can answer:

1. Now you have the state machine as a LUA file. How can it be visualized, that is, represented as a graph ? Is any additional translates needed in the SCXML file itself or another format such as JSON ?

2. As I see it, such an opportunity is necessary so that the state machine can be serialized at any time. For example, such a situation: one process starts from scratch with a certain state machine, then in a certain situation it stops the machine’s operation and packs this machine into some format so that all internal parameters and states at that moment are saved. It transfers this file to another process, which unpacks this file and starts the machine from the moment it was stopped in the previous process. Is it possible ?

[stetre]

Point 1 is an application issue. Different applications may deal with it in different ways, according to their needs, requirements, tools available, taste, etc.

A statechart in MoonSC is nothing else than a Lua table having the simple format explained in the Statecharts section of the manual. Such a table can be translated from/to a SCXML document in a pretty straightforward way (I know it because I did it by hand for some ~200 docs in the past few days ;-) ), but it can also be translated to/from any other equivalent format you like, which may include other formalisms as well as serialization formats, JSON or whatever you like.

As for point 2 I have to think about it. I don't recall if this a mechanism is explicitly considered by the SCXML Recommendation. Maybe it can be designed in the statecharts themselves, using standard SCXML constructs?

[EduardShaid]

Yes, I see you have done a good job. But it is necessary to conduct more testing.

With regard to serialization, it may be possible to use the logging of all events for the state machine in a separate file. Then it is possible to re-play this state machine for this log file in the new process to its last state, that is, its recovery and then further work. But there is another problem with the storage of such a log file. It can become big with time.
On the other hand, I do not quite know the language LUA. Is it possible that the tables themselves already have the property of retaining their internal state and parameters?

[EduardShaid]

Аs you specify in your manual: "Each session has a dedicated Lua environment (_ENV) that represents your data model...".
Is it possible to save and restore the environment in LUA ?

[stetre]

The environment in Lua is a plain table, so in principle yes, it could be saved and restored
(not without some difficulties though, because it contains tables that contain tables and so on).
But I think it would be overkill because much of the content of the environment is stuff that can be recreated easily, not state data.

However, as I see it after having thought about it for a while, the possibility to stop a statechart during its execution/save its state/restart it elsewhere (perhaps on another processor?) should really be designed in the statechart itself using standard SCXML constructs. For example such a statechart should start in an 'idle' state, waiting either for a 'start' or 'resume' event (the latter containing saved state as parameters) and accept as input a 'stopandsave' event in a transition that saves the relevant state and enter a <final> that returns the state in the <donedata>. The application could then create another fresh session and send it the <donedata> in a 'resume' event.

I don't think that adding this capability as a generic feature in the engine would be a great idea. I see edge cases coming out from every corner... Tthe semantical complexity of such a thing as a general feature would be that of the <history> element (which already is a mess) times N where N>>1.

EDIT: Fixed the <s and the > (damn...)