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 <[EMAIL PROTECTED]> 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.
>
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 ;-)
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.
> 1. SCXMLSerializer
See recent post with subject starting with "[SCXML] SCXMLSerializer
and package reorganization"
> 2. Decouple Execution Context from the SCXML Model
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.
>
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
