commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ate Douma <>
Subject [SCXML][DISCUSS] Towards specification compliance - roadmap and next steps
Date Wed, 26 Feb 2014 23:48:35 GMT
Hi SCXML and other community members/developers,

After working on the new Commons SCXML 2.0 code base for a few months, doing 
some cleaning up and providing minor fixes and improvements, I think we now need 
some more serious and drastic changes...

The goal (as it always has been) for Commons SCXML 2.0 is to reach specification 
[1] compliance.
But after thoroughly reviewing the current implementation, this IMO won't be 
possible without some major changes.

The top 'issues' I've identified are:

a) The SCXML model itself: there are several model elements not (properly) 
supported right now, or in a way incompatible with the current specification, or 
in a way the specification provides/requires an alternative solution for.

b) SCXML datamodel: the (XPath/XML) datamodel currently implemented in Commons 
SCXML is considerably out-of-sync and incompatible with what the specification 
Most importantly: the local/nested 'scope' of datamodel definitions (and 
contexts) in Commons SCXML, while very flexible and great in theory, is in 
conflict with the current specification requirements.
And actually making things *much* more difficult and complicated than what the 
specification asks for...

c) Event processing: the current internal event processing is in violation with 
the current specification. Like for example all internal events on the queue are 
processed together (one micro step) while the specification requires these to be 
processed in sequence. This affects the behavior and semantics of SCXML 
processing, and as such I consider this as one of the most problematic issues 
right now.

d) A bunch of other specification requirements currently not at all supported or 
only badly so. Examples are (supposed read-only) system variables, session 
support, external communications.

e) Optional features, like adding ECMAScript+JSON datamodel support, possibly 
HTTP Event I/O Processor support.

All of the above (except e) should be solved and done to reach a reasonable 
level of compliance with the specification. Which is *a lot* of work :)

To give this a reasonable chance of success, I have the following proposal:

1) Accept serious changes in the implementation, including breaking changes 
(with regard to the outdated 0.9 version).
Also: ignore/forget about deprecation support if practically unfeasible or too 

2) drop and remove, at least *for now*, support for many/most of the 
outdated/incomplete 'integration' features, like Apache Shale (which is in the 
attic) and JSF, Servlet/JSP, Android, Rhino/E4X (ECMAScript for XML, 
outdated/unsupported spec.).
This also includes deleting all the outdated and incomplete/broken documentation 
around them.
We *can* add support back for (some of) these later, after we reached reasonable 
compliance *and* there is actual interest (and help) for re-implementing and 
testing them.

3) Start working on the first 4 top 'issues' of the list above, a) to d).
Technically I think this most effectively can be done in the following order: c, 
b, a and then d.
And while doing this, the requirements for optional features like e) should be 
kept in mind as well.

But most important are steps 1) and 2), otherwise step 3) will IMO practically 
impossible to achieve.

Any feedback to the above is very welcome.

I'd like to start cranking on this ASAP, also with regards to my presentation on 
Commons SCXML 2.0 at the ApacheCon in Denver coming April [2] :)

So I hope I also can assume lazy consensus with little or no feedback ;)

With kind regards, Ate


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

View raw message