scxml: planning and versions

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

scxml: planning and versions

rinke
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.

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 svn.apache.org repository a good idea (1.0)?

Can you give some clues in when the first 2.0 release can be expected?

Thanks, Rinke

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


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: scxml: planning and versions

Woonsan Ko
Hi Rinke,

Welcome! And that's great to hear about your project!
The roadmap is described here: http://commons.apache.org/proper/commons-scxml/roadmap.htmlI would recommend you to use 2.0-M1 instead because the milestones (M0 and M1) were actually done based on the J6 branch and included proper cleanups and basic alignments to the latest specification.

Kind regards,

Woonsan

[1] http://mail-archives.apache.org/mod_mbox/commons-dev/201404.mbox/%3C533D4314.40805@...%3E
 


On Tuesday, April 15, 2014 5:30 AM, R.C. Hoekstra <[hidden email]> 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.
>
>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 svn.apache.org repository a good idea (1.0)?
>
>Can you give some clues in when the first 2.0 release can be expected?
>
>Thanks, Rinke
>
>by the way: thanks for all the good work done. I think it is a great project.
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [hidden email]
>For additional commands, e-mail: [hidden email]
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: scxml: planning and versions

Ate Douma
In reply to this post by rinke
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 svn.apache.org 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
solve.
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

[1]
http://events.linuxfoundation.org/sites/events/files/slides/ApacheConUS2014%20-%20Apache%20Commons%20SCXML%202.0.pdf
[2]
http://mail-archives.apache.org/mod_mbox/commons-user/201404.mbox/%3C533D4314.40805%40douma.nu%3E
[3] http://commons.apache.org/proper/commons-scxml/roadmap.html

>
> 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: [hidden email] For additional
> commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: Re: scxml: planning and versions

rinke
In reply to this post by rinke
Hi Ate, Woonsan,

thanks for the long answer; sorry for my late reply, I was away for a few days.

Good to hear you are really interested in our use-case, Ate.

You're asking what specific specification features we will be using now, or in the near future. To be honest; I don't know yet. At the moment we are still in the stage of settings things up, and we are exploring all the possibilities scxml offers to our project.

Because to launch out here about our project features wouldn't fit anymore in the subject of this thread, I will soon post a subject about our project, and then maybe you guys can advise us some more on the best features to use.

best regards, Rinke
---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: scxml: planning and versions

Ate Douma
Hi Rinke,

On 19-04-14 22:15, R.C. Hoekstra wrote:

> Hi Ate, Woonsan,
>
> thanks for the long answer; sorry for my late reply, I was away for a few
> days.
>
> Good to hear you are really interested in our use-case, Ate.
>
> You're asking what specific specification features we will be using now, or
> in the near future. To be honest; I don't know yet. At the moment we are
> still in the stage of settings things up, and we are exploring all the
> possibilities scxml offers to our project.

OK, that is already good to know :)

>
> Because to launch out here about our project features wouldn't fit anymore in
> the subject of this thread, I will soon post a subject about our project, and
> then maybe you guys can advise us some more on the best features to use.

Great, looking forward to your email.

FYI: I'll be away on a trip the coming 10 days, with little to no connectivity,
so my feedback might come in only after I return.

Regards, Ate

>
> best regards, Rinke
> --------------------------------------------------------------------- To
> unsubscribe, e-mail: [hidden email] For additional
> commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]