Hi Ben,
Very interesting use-case: Commons SCXML into space :)
I've only briefly looked at the image you shared, but it is difficult for me to
comprehend the exact usage or how this is represented in SCXML.
If you'd be able to share some example SCXML document, and how parts of that
should be(come) dynamically injected/removed, it might become easier to
understand what your requirements are.
Thanks,
Ate
On 26-10-14 15:45, Benoît Thiébault wrote:
Hi and thank you for your answers
It isn't really clear to me under what conditions you are executing the
existing state chart.
We are developing an open source scientific software called SPIS (for
Spacecraft Plasma Interactions Software http://dev.spis.org). As its name
implies, it models the physics of space plasmas around in-orbit satellites, but
I guess that's off-topic ;-).
We use a state chart to represent what we call the "modelling chain" (cf.
attached picture), which is a generic definition of the steps to go through for modelling
a spacecraft.
The software is based on OSGi and is composed of modules (called bundles in
OSGi terminology) that are loaded dynamically. Roughly, we can say that each
module provides the features necessary to perform one step of the modelling
chain: we have a spacecraft geometry modeller, a mesher, an editor for initial
and boundary conditions, etc. When the application starts, all bundles are
loaded (we don't know the order in which they are loaded, it's the OSGi
framework that decides depending on module dependencies). As of today, we have
a unique, central state engine that defines the steps of the modelling chain
and the modules trigger the transitions when they are done.
For now, there is just a single version of the software, but the idea is to be
able, in the future, to provide different versions, with different capabilities
depending on the modules provided. It is somewhat similar to what you can do
with Eclipse distributions (Eclipse is OSGi-based by the way): depending on the
modules installed, you have a Java IDE, a C++ IDE or a Fortran IDE (or
something completely different). In our case, we could model different physics
and modify the modelling chain on the fly depending on the loaded modules. We
call that an IME (Integrated Modelling Environment). In that scenario, we would
like the modules to inject in the central state chart the steps they are able
to provide, not like today where it isn't dynamic: the state chart is defined
centrally and the modules cannot modify it.
The solution you suggest is indeed interesting and could solve our problem. I
was just wondering what was already coded in SCXML API and what needed to be
done (either on our side or in the library).
Jake's suggestion is also interesting, but in that case I wonder how would the
different state diagrams interact with each other.
Kind regards,
Ben
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
