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-unsubscr...@commons.apache.org > For additional commands, e-mail: user-h...@commons.apache.org >
--------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
