commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ate Douma <>
Subject Re: scxml: planning and versions
Date Tue, 15 Apr 2014 21:17:20 GMT
Hi Rinke,

On 15-04-14 11:29, R.C. Hoekstra wrote:
> Hi all @ commons scxml,
> We're a university team of scientists working on multi agent simulations of
> tropical diseases for a world health organization project. A disease can be
> considered as a state machine, with the patient going through various states
> and transitions, each triggering new events.

Interesting use-case which I definitely like to hear more details about!

> For our project we're diving into commons scxml. However I'm a bit confused
> about what version would be best to use. I'm a bit afraid that the 0.9
> official release is so much outdated that it will not be compatible with the
> coming release, so we would end up with lots of changes to be made when
> updating. On the other hand working on a release which is still under
> development or unstable doesn't seem a good idea.
> Is the J6 branch on the repository a good idea (1.0)?

You better no longer start with the 0.9 release.
It is outdated for sure and no longer actively maintained.
But true enough, the 2.0 development hasn't completely stabilized out either.

The J6 branch won't give you much benefit above the 0.9 release though: it is 
about just as outdated, and neither forwards compatible with the the W3C SCXML 
specification, nor the current 2.0 development in trunk for that matter.

However, the latest milestone tag M1 towards the 2.0 release should give you a 
reasonable stable and reliable basis to start with. So much so that we actually 
are already using it in our product (see [1], slides 14-15 for some background 
on our use-case).
And as Woonsan just emailed and which I'm just repeating here for completeness: 
instructions to get started with the M1 milestone can be found in an earlier 
email I send out to this list [2].

Anyway, it really depends on which of the SCXML specification features you need 
right now, today, or possibly very soon.
As indicated on the roadmap [3], not everything is completely implemented or 
properly aligned with the requirements of the specification yet.
Especially certain aspects around the datamodel handling, external 
communications and specific expression (language) features still needs some 
major changes and improvements.

However, except for some temporarily dropped language features (milestone 0), 
most if not all features available from the 0.9 release still also work in the 
current 2.0 trunk, so from an SCXML semantics perspective you're far better off 
with the latest milestone already.

The real significant changes so far are in the SCXML document model (with 
*added* capabilities, not so much dropped anything other than now being more in 
line with the specification), the processing algorithm, and the internal APIs.

We are aggressively working towards further improving the alignment with the 
specification and I expect a next milestone tag might be possible in a few weeks 
time. This *will* result in additional changes, but mostly in the internal APIs, 
and probably some of the public/external interfaces (SCXMLExecutor etc.).

So, upgrading between milestones will cause some coding impact, but should not 
change the SCXML state machine semantics itself, other than providing more 
support for and alignment to the specification.

What definitely will help speed things up is if others can test drive it and 
provide feedback on what is working or not yet :)

I'm definitely interested to hear more about your team requirements, what 
specific SCXML features you need and how you intend to integrate and execute 
Commons SCXML.
If feasible I might be able to adjust the work planning if it would help you out 
with specific features sooner, if you are willing to test drive and provide 
feedback and/or maybe even directly contribute?

Any help for sure is welcome and much appreciated!

> Can you give some clues in when the first 2.0 release can be expected?
That is the toughest question to answer :)

It depends: on the amount of time we can make free to work on this, the amount 
of help and contributions provided, and of course the technical hurdles still to 
So I cannot give you a precise answer, but personally I think/hope it might be 
doable sometime this summer, or maybe even a bit sooner with the help and 
contributions of others ...

Regards, Ate


> Thanks, Rinke
> by the way: thanks for all the good work done. I think it is a great
> project.

Thanks, great to hear you like it!

> --------------------------------------------------------------------- To
> unsubscribe, e-mail: For additional
> commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message