On Feb 27, 2014 4:35 AM, "Ate Douma" <a...@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 <a...@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-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org >
