Re: [SCXML][DISCUSS] Towards specification compliance - roadmap and next steps

[Ate Douma <at...@douma.nu>]

Thanks for the positive and supportive feedback Matt and Benedikt!

I'll now also assume lazy consensus from the others here and start with 
executing according to my proposal.

You can expect some major cleanup and removal of outdated features, including 
documentation, for SCXML shortly...

Regards, Ate


On 27-02-14 14:46, Matt Benson wrote:
> On Feb 27, 2014 4:35 AM, "Ate Douma" <at...@douma.nu> wrote:
>>
>> On 27-02-14 11:30, Benedikt Ritter wrote:
>>>
>>> Hello Ate,
>>>
>>> without knowing SCXML or the specs here are my thought about your
> proposals
>>> (just from a apache commons point of view ;-):
>>>
>>>
>>> 2014-02-27 0:48 GMT+01:00 Ate Douma <at...@douma.nu>:
>>>
>>>> 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 requires.
>>>> 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 complicated.
>>>>
>>>>
>>> Sounds good to me, as long as the requirements for breaking BC are met
>>> (changing package names and maven coords)
>>
>> Sure, and already taken care of.
>> When we started on the new SCXML 2.0 trunk, we changed both the package
> and the maven coordinates accordingly, so we're all set for this.
>>
>
> It is nice to try and preserve backward compatibility wherever possible but
> once packaging, etc. has been changed it is not essential. The other points
> of your proposal sound similarly reasonable.
>
> Matt
>
>>
>>>
>>>
>>>> 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.
>>>>
>>>
>>> Makes sense.
>>>
>>>
>>>>
>>>> 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.
>>>>
>>>
>>> go for it! :-)
>>
>> Thanks!
>>
>>
>>>
>>>
>>>>
>>>> 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 ;)
>>>>
>>>
>>> The only thing we are crazy about is making sure users won't get into jar
>>> hell when using our libs. So we're trying to make sure incompatible
> classes
>>> can never end up in the same class path by changing the package name.
> Since
>>> we already have commons-scxml in maven central [1] we need to change the
>>> package name.
>>
>>
>> Yup, see above.
>>
>>
>>>
>>> Keep up the good work!
>>> Benedikt
>>
>>
>> Thanks for the positive feedback. Much appreciated!
>>
>> Ate
>>
>>
>>>
>>> [1]
>>>
> http://search.maven.org/#artifactdetails%7Ccommons-scxml%7Ccommons-scxml%7C0.9%7Cjar
>>>
>>>
>>>>
>>>> With kind regards, Ate
>>>>
>>>> [1] http://www.w3.org/TR/scxml/
>>>> [2] http://sched.co/1dlTw2L
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>


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