Mailing-List: contact user-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Users List" <user@commons.apache.org>
From: "R.C. Hoekstra" <r.c.hoekstra@erasmusmc.nl>
To: "user@commons.apache.org" <user@commons.apache.org>
Subject: Re: Re: [scxml] update and progress?
Thread-Topic: Re: [scxml] update and progress?
Thread-Index: AdEup2xQcfhx+xv0QP+xU5HOsXNCBw==
Date: Fri, 4 Dec 2015 15:21:18 +0000
Message-ID: <521542E73D0D214AB9D88954DDC2FB606AA6950A@EXCH-HE01.erasmusmc.nl>
Accept-Language: en-US, nl-NL
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Hi Ate,=20

thanks for answering.=20

As for the datamodel...
Well, I put the stuff in our project which depended on the datamodel on hol=
d. 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 seri=
ous changes.=20

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 mor=
e important than the choice on which language support will be there and whi=
ch not.=20
So I can perfectly live with JSON. And if your proposal leads to greater ea=
se of use and faster implementation, that is fantastic. Please do so.=20

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 projec=
t.

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, regre=
ttably.

That doesn't mean I (and Woonsan) are no longer interested in working on th=
is,
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 under=
stand
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 an=
d
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 X=
Path
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 la=
ck of
interest and too many complications and limitations with XPath to be able t=
o
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 lan=
guage
support for Commons SCXML 2.0, before moving on with completing and wrappin=
g up
the goals for M2.

This however is a very radical change, including dropping the support for t=
he
Data() and just added Location() functions for the Jexl and Groovy language=
s.
Instead however, I would like to replace this by providing proper JSON data=
model
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 supp=
ort,
than this might be a no go, unless you are fine with migrating from XML/XPa=
th to
JSON instead.

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

Kind regards,
Ate

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