On 25-10-14 09:22, Benoît Thiébault wrote:
Hi everyone,
I am very pleased to learn that SCXML is back online and that new evolutions
are coming with version 2.0. Congrats and good luck to the development team!
I already use SCXML 0.9 in one of my applications and one feature I was
missing was a more dynamic state engine. My application is OSGi-based and
thus very dynamic: modules come and go at runtime. What I wanted to do was to
be able to modify the state diagram at runtime: when a new bundle is loaded,
it injects its own state chart as a sub-set of the existing state chart. If I
understood SCXML correctly, this was not really possible with 0.9. Is it
planned for future versions?
It isn't really clear to me under what conditions you are executing the existing
state chart.
Can't you simply rewrite (extend) the underlying SCXML XML document and then
reload/reset the statemachine with the updated document?
That should be trivial to do and always have been possible.
Or do you need to retain the current (context) state?
That might be tricky as the current state is based on and tied to the SCXML
model, so if (sub)modules 'come and go' dynamically, you would need to ensure
the SCXML state is still valid and representative for the model.
Maybe something like the following is an option?
a) lock down the statemachine (disallow concurrent access/execution)
b) somehow capture/clone the current internal state externally
c) update your SCXML document as you need, using plain XML API or Commons SCXML
Java API
d) reload the SCXML statemachine
e) restore the previously captured state (step b)
f) unlock the statemachine
AFAICS the above should be doable without changes to the current Commons SCXML
implementation (and likely even with the 0.9 version), but for step b and e to
probably need to hook into (possibly extend) the Commons SCXML Java API.
If you have more concrete problems or otherwise think Commons SCXML really need
more dynamics support I'd be happy to discuss them further, but you need to be
more specific for me to understand your requirements.
And of course I'd welcome contributions as well :)
Regards,
Ate
Kind regards,
Ben
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
