commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benoît Thiébault <thieba...@artenum.com>
Subject Re: [SCXML] Plans for making SCXML more dynamic?
Date Sun, 26 Oct 2014 14:45:55 GMT
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: user-unsubscribe@commons.apache.org
> For additional commands, e-mail: user-help@commons.apache.org
> 




Mime
View raw message