commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "R.C. Hoekstra" <r.c.hoeks...@erasmusmc.nl>
Subject Re: Re: [scxml] update and progress?
Date Fri, 04 Dec 2015 15:21:18 GMT
Hi Ate, 

thanks for answering. 

As for the datamodel...
Well, I put the stuff in our project which depended on the datamodel on hold. We wanted to
apply a datamodel in order to separate the state flow logic and the numbers used in it, but
we haven't done that up to now, because I was afraid that the datamodel on scxml commons would
become subject of serious changes. 

So for us it's still very flexible, as we didn't start with that part yet. I have a slight
personal preference for at least the xml in the datamodel, but it's not that important. For
us the progress of the project is much more important than the choice on which language support
will be there and which not. 
So I can perfectly live with JSON. And if your proposal leads to greater ease of use and faster
implementation, that is fantastic. Please do so. 

The support for java8 is also fine with me. We're doing everything in java 8.

So conclusion: your proposal is supported from over here!

best regards, Rinke




Hi Rinke,

On 2015-11-24 12:24, R.C. Hoekstra wrote:
> Hi Ate, Woonsan,
>
> I was wondering if you guys could give us an update on the progress of
> SCXML, and tell us how it's going.
>
> Specifically, I was wondering if you could give us any clue on when
> Milestone 2 can be expected. I'm looking forward to the new datamodel
> features with great interest.
>
> I don't see much questions and activity on the mailinglist on scxml, but I'd
> like you to know that we are still very enthousiastic on the scxml project.

That is great to hear, and thank you for saying so!

Obviously there hasn't been much progress since early this year :(

Main reason for this is that the current M1 release has been sufficient for our
current use-cases, so far, and we thus right now don't have a real business
driver nor concrete budget/time to work on this during working hours, regrettably.

That doesn't mean I (and Woonsan) are no longer interested in working on this,
but can only do so on our own account outside office hours.
And as we've been very busy with lots of other work, you probably can understand
that working on Commons SCXML kind of ended up on the back burner.

Also there hasn't been much input from the 'community' either...

That said, your question tricked me in reviewing again the current state and
outstanding issues, for M2 and beyond, and what can/should be done next.

And I now realize again that another reason why I 'dropped the ball' since last
February is that at that time I reached several technical and frustrating
problems in the current functionality, concerning both the Javascript and XPath
datamodel support.

As you might know, the now final SCXML 1.0 specification at the end dropped the
XPath support because there were no concrete implementations, because of lack of
interest and too many complications and limitations with XPath to be able to
provide a proper implementation.

And those same complications and limitations are also causing serious and
invasive problems in the (overall) implementation in Commons SCXML.
Honestly, I'm fed up with the XML/XPath datamodel as it is hampering and
complicating the implementation way too much.

Therefore, I want to propose to completely drop XML/XPath datamodel and language
support for Commons SCXML 2.0, before moving on with completing and wrapping up
the goals for M2.

This however is a very radical change, including dropping the support for the
Data() and just added Location() functions for the Jexl and Groovy languages.
Instead however, I would like to replace this by providing proper JSON datamodel
support, not just for Javascript but also the Jexl and Groovy languages.
Technically and functionally this will be:
- much easier and straightforward to implement with a lot less edge-cases
- much easier and practical to use

And in addition, for proper Javascript support we should move to Java 8
(Nashorn Javascript engine), and thus drop support for Java 6 and 7.

But before doing so, this needs to be discussed and agreed upon by the
Commons SCXML community, however small a group that might be nowadays.

I hope you and others can comment on this idea and provide feedback if you
would be OK, or why not.
If for example you or others strongly depend and rely on XML datamodel support,
than this might be a no go, unless you are fine with migrating from XML/XPath to
JSON instead.

If we can make this decision: drop XML/XPath support, add JSON as alterative,
and move to Java 8 as minimum, then we can move forward much faster and with a
much cleaner and leaner implementation.
I'd then be happy and motivated again to continue working towards M2 shortly,
and I know Woonsan is willing to pitch in then as well.
That might still need a few months work to complete, but definitely overseeable.

Kind regards,
Ate

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


Mime
View raw message