commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Benson <gudnabr...@gmail.com>
Subject Re: [SCXML][DISCUSS] Towards specification compliance - roadmap and next steps
Date Thu, 27 Feb 2014 13:46:01 GMT
On Feb 27, 2014 4:35 AM, "Ate Douma" <ate@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 <ate@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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message