On 26-02-14 15:04, Jim Barnett wrote:
Ate,
It's very good news that Commons SCXML is still active.
Oh yes, and we have the intent to bring it back in line and compliance with the
specification for the 2.0 release.
I have been monitoring this list for a while and not seen any mention of it.
You might have, if you also monitored the d...@commons.apache.org list :)
That is where we have been discussing the reactivation of Commons SCXML.
Commons SCXML has been kind of dormant for several years, with as result that
the current implementation isn't really in sync or compliance with the latest
specification.
However, since last October we 'rebooted' the project (slowly) and started with
basic cleanup and some initial fixes and minor improvements.
And even not so minor improvements like preliminary Groovy scripting support.
I'm now ready and about to come up with a plan and roadmap for more drastic
changes in the internals and semantics of the SCXML processing, which are really
needed to be able to get to spec compliance.
That'll take a bit for sur, but I've digested and dissected the specs now often
enough to have a reasonable idea of what is required first :)
Have you looked at the W3C test plan for SCXML
http://www.w3.org/Voice/2013/scxml-irp/?
Yes I did. And I definitely will start using and validating against it *once*
we've reached a minimal level of spec compliance needed to even start executing
those tests...
Right now, its pointless to even try.
Mind you: Commons SCXML *does* work nicely within its current limitations, and
we (my company) actually already use it integrated in our product.
But getting it spec compliant definitely is high on our list.
I'd also be interested in knowing what optional features you plan to support.
I haven't given that much thought yet. Getting the required features working is
first priority.
For now our focus is on getting Commons SCXML 2.0 compliant as 'plain' Java
back-end engine only.
I actually intend to first get rid of much of the now too
old/outdated/incomplete stuff like Shale/JSF/Servlet/E4X support as they only
complicate the effort in this phase.
We can later rebuild support back in for such usages if/when there is enough
interest for it (and concrete help doing it).
Will you support the XML datamodel or the DOM Event I/O processor?
The XPath/XML datamodel has been the only (type of) datamodel Commons SCXML
supported. For sure we'll continue supporting that, and (need to) improve/fix it.
I also have the intend to add Ecmascript+JSON datamodel support.
I don't expect we'll add DOM Event I/O processor support any time soon though.
Like I said above, our primary focus is on Java based back-end use-cases only
and not front-end/browser integration.
But of course, anyone with an itch, and the capacity to scratch it properly, is
more than welcome to join the project and start helping out!
Which is also one of the goals with my presentation at the ApacheCon:
making the community aware of the re-activation of Commons SCXML, the roadmap
we're working on and raising interest to participate and help out.
Kind regards, Ate
p.s. I probably will chime in on the www-vo...@w3.org list soon once I start
hacking on the semantics of the SCXML processing :)
Best Regards,
Jim Barnett
-----Original Message-----
From: Ate Douma [mailto:a...@douma.nu]
Sent: Wednesday, February 26, 2014 5:38 AM
To: Commons Users List
Subject: [ANNOUNCE] [ApacheCon NA2014] Using Apache Commons SCXML 2.0: a
general-purpose and standards based state machine engine
Just like to inform you all I'll be presenting on Commons SCXML 2.0 at
ApacheCon North America 2014 (Denver, April 7-9).
For details and schedule see: http://sched.co/1dlTw2L
Regards, Ate
---------------------------------------------------------------------
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
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org
