commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ate Douma <...@douma.nu>
Subject Re: [ANNOUNCE] [ApacheCon NA2014] Using Apache Commons SCXML 2.0: a general-purpose and standards based state machine engine
Date Wed, 26 Feb 2014 22:24:33 GMT
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 dev@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-voice@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:ate@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: user-help@commons.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
> For additional commands, e-mail: user-help@commons.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org


Mime
View raw message