[scxml] a few observations, issues before release

[Tim OBrien <to...@discursive.com>]

I'm interested in the SCXML codebase, but before I could vote +1 for promotion, I'm generally
thinking that the following issues need to be discussed.  I apologize if this is blocking RDC.

1. SCXMLSerializer 

Right now the code to serialize an SCXML object is a Visitor pattern that constructs XML using a
series of StringBuffers.  The code to read this XML document alrady uses a straightforward set of
Digester rules and the project already depends on commons-digester.

*Alternative: Add a dependency to commons-betwixt, map the model package to XML.  Instead of
writing Digester rules for reading and constructing Strings for writing, use the betwixt mapping
files as a single point of translation.

The current SCXMLDigester isn't trivial by any means, but I think it would be easy to implement
the external source rule.  The current SCXMLDigester plays two roles, first it sets up the
Digester rules and "Digests" the XML, but it also does a bit of post-processing in updateSCXML.  I
think the component would be well served to separate everything that has to do with serialization
to/from XML into a separate package and to move some of this postProcess that happens in
updateSCXML somewhere else.

2. Decouple Execution Context from the SCXML Model

Right now, the Context passed into the class that parses the XML and creates the SCXML object is
the global execution context.  You pass in a JexlContext when you are parsing the SCXML model, it
is assigned to all of the State objects.

So, bear with me, assume I have a SCXML document that represents the valid states of a stopwatch
(ready, running, paused, stopped).  The SCXML models the watch in a way similar to the microwave
sample in the Working Draft, it uses a reference to a "timer" variable.  To do this with the
current implementation of SCXML, I would need to do the following twice (assuming a JexlContext):

  a. Create a JexlContext
  b. Populate the JexlContext with the appropriate variables
  c. Call SCXMLDigester passing in the JexlEvaluator and the JexlContext I want to execute this
state machine with
  d. Create an instance of SCXMLExecutor, pass it the SCXML from step c.

For each watch I need to model in this application, the implementation forces me to parse that
SCXML document with Digester every time I want to model a separate StopWatch.  In the application
I'm interested in using this in, hundreds of documents in a content management system are going to
be modeled as individual state machines, I would hate to have to parse an SCXML file for each
individual document.

* Alternative: Provide a mechanism that allows you to clone an SCXML  instance so that you can
create a separate SCXMLExecutor that can model the same statemachine with an isolated Context.

* Better Alternative: States do not "have" a context.  Take the context property off of the State
and change executeActionList in SCXMLSemanticsImpl to get the Context from the Executor.  
Likewise, Transitions do not have a "notificationRegistry", take that property off of a transition
and just have the SCXMLSemanticsImpl get the notificationRegistry from the Executor.

I don't think this is a terribly difficult idea, and decoupling the description of the FSM from
the execution state, would also make it much easier to persist either one.  

3. Is SCXML appropriate for Commons? 

Commons SCXML might not be appropriate for Jakarta Commons.  See the recent discussion on general@
about componentizing different parts of Jakarta.  I'm not going to fight this one because I think
we're in a time of transition, but commons-scxml might ultimately benefit from producing a number
of separate artifacts.  scxml, scxml-faces, scxml-shale, etc.

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

Re: [scxml] a few observations, issues before release

[Rahul Akolkar <ra...@gmail.com>]

On 1/18/06, Tim OBrien <to...@discursive.com> wrote:
> Rahul, my emails are a tad long, eh?  Apologies in advance.
>
<snip/>

Nah, that was a comment about the length after *I* replied to your
email, and subsequently found it better to fragment it out into bite
size chunks in separate threads.


>
> > > 3. Is SCXML appropriate for Commons?
> > >
<snap/>
> >
>
> Understood.   Let's just acknowledge that if scxml is a successful component, and if it
> experiences the level of interest I think it warrants, it could very well go the route of
> httpclient.
>
<snip/>

Ack'ed.

It can potentially go places, thats my opinion as well.


> At the moment, it is a simple, narrow component focused on scxml.   I think it would be wise to
> think about the long term.  Jakarta is going to undergo some transitions over the next year (see
> general@ thread from last week), and during that transition we should put a flag on scxml as one
> of the components that we need to think about as being qualitatively different from something like
> Commons Lang.
>
> But, short-term, promotion to proper makes sense.
>
> <snip/>
>
> You are right about Jakarta state transitions not being nearly as clean as an ideal state machine.
>
<snip/>

All this makes sense to me.

-Rahul

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

Re: [scxml] a few observations, issues before release

[Tim OBrien <to...@discursive.com>]

Rahul, my emails are a tad long, eh?  Apologies in advance.

--- Rahul Akolkar <ra...@gmail.com> wrote:

> > 3. Is SCXML appropriate for Commons?
> >
> > Commons SCXML might not be appropriate for Jakarta Commons.  See the recent discussion on
> general@
> > about componentizing different parts of Jakarta.  I'm not going to fight this one because I
> think
> > we're in a time of transition, but commons-scxml might ultimately benefit from producing a
> number
> > of separate artifacts.  scxml, scxml-faces, scxml-shale, etc.
> >
> <snip/>
> 
> Yup, seen that thread. However, IMO, moving SCXML *again* will amount
> to handing off what I will call a "death by Commons" to this
> component. We moved the codebase from Taglibs because I completely
> agreed with Martin's (martinc) suggestion at the time that this code
> is useful beyond its first usecase in Taglibs. Very few of those who
> supported the RDC development and release are present in Commons which
> means we started mostly from scratch in terms of developer community.
> Now we're at a point in Commons where the veto vote from Martin (mvdb)
> however acknowledges the sustained development effort around Commons
> SCXML. The component will lose this "history" once again if we go
> elsewhere. ATM, IMO, Commons is the best place for this implementation
> to live in Jakarta (or Apache even).
> 

Understood.   Let's just acknowledge that if scxml is a successful component, and if it
experiences the level of interest I think it warrants, it could very well go the route of
httpclient.  

At the moment, it is a simple, narrow component focused on scxml.   I think it would be wise to
think about the long term.  Jakarta is going to undergo some transitions over the next year (see
general@ thread from last week), and during that transition we should put a flag on scxml as one
of the components that we need to think about as being qualitatively different from something like
Commons Lang.

But, short-term, promotion to proper makes sense.

<snip/>

You are right about Jakarta state transitions not being nearly as clean as an ideal state machine.
 

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

Re: [scxml] a few observations, issues before release

[Rahul Akolkar <ra...@gmail.com>]

The email exceeded the maximum length I myself am comfortable with
when it comes to list emails, so I've spawned new threads for the two
"technical" topics to keep message size manageable. But a couple of
things are discussed here as well.

On 1/14/06, Tim OBrien <to...@discursive.com> wrote:
> I'm interested in the SCXML codebase, but before I could vote +1 for promotion, I'm generally
> thinking that the following issues need to be discussed.  I apologize if this is blocking RDC.
>
<snip/>

Any issues raised about the codebase must be addressed before a
release. A release dependency graph should not affect quality of
artifacts produced, so the conditional apology is completely
unnecessary ;-)

<sidebar>The RDC taglib is the only taglib in Jakarta Taglibs that has
seen steady new development over the last year (new tags are still
being submitted for addition), and IMO, it deserves a more recent
release ASAP having seen many useful additions since 1.0 including a
SCXML dialog management strategy. But that discussion is for another
list.</sidebar>


> 1. SCXMLSerializer
<snip/>

See recent post with subject starting with "[SCXML] SCXMLSerializer
and package reorganization"


> 2. Decouple Execution Context from the SCXML Model
<snap/>

See recent post with subject starting with "[SCXML] Decoupling
Execution Context from the SCXML Model"


> 3. Is SCXML appropriate for Commons?
>
> Commons SCXML might not be appropriate for Jakarta Commons.  See the recent discussion on general@
> about componentizing different parts of Jakarta.  I'm not going to fight this one because I think
> we're in a time of transition, but commons-scxml might ultimately benefit from producing a number
> of separate artifacts.  scxml, scxml-faces, scxml-shale, etc.
>
<snip/>

Yup, seen that thread. However, IMO, moving SCXML *again* will amount
to handing off what I will call a "death by Commons" to this
component. We moved the codebase from Taglibs because I completely
agreed with Martin's (martinc) suggestion at the time that this code
is useful beyond its first usecase in Taglibs. Very few of those who
supported the RDC development and release are present in Commons which
means we started mostly from scratch in terms of developer community.
Now we're at a point in Commons where the veto vote from Martin (mvdb)
however acknowledges the sustained development effort around Commons
SCXML. The component will lose this "history" once again if we go
elsewhere. ATM, IMO, Commons is the best place for this implementation
to live in Jakarta (or Apache even).

Couple of relevant bits related to your comments above-

 * Jakarta "transitions" - Unlike SCXML transitions (where state chart
theory implies they must take inconspicuous amounts of time), these
can be *quite* long. Case in point, WebComponents (I think thats what
we're calling it now?). I would help move that one along, but I don't
know where to start ;-) I won't be holding my breath, these things
happen when they do.

 * Separate artifacts - Agreed, indeed, thats the vision in the
proposal for the SCXML component. However, this does have a lot of
uncertainties. Take the scxml-shale artifact you refer to, for
example. Besides the fact that I get a direct route to the runtime
from the modeling layer, I use SCXML with Shale due to a couple of
things that I fancy [1],[2]. I am planning on submitting an
enhancement request once a Commons SCXML release is out (I see no
point on doing it against unreleased code). However, it is upto the
Struts Shale team whether they accept it / find value in it. If that
is the case, we can definitely enhance the support for Shale dialogs
and produce a Shale specific build artifact. If we end up outgrowing a
"Commons component" footprint, we can cross that bridge then as well.

-Rahul

[1] http://people.apache.org/~rahul/shale/dialog-delegation/
[2] http://people.apache.org/~rahul/shale/align-dialog/

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