commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rahul Akolkar <>
Subject Re: [SCXML] Suitability as a Commons project (Was: Moving to commons proper)
Date Fri, 09 Sep 2005 00:41:13 GMT
On 9/8/05, Stephen Colebourne <> wrote:
> Rahul Akolkar wrote:
> > As I return from big sky country, I see this probably warrants its own thread -
> >
> > On 9/4/05, Stephen Colebourne <> wrote:
> > <snip/>
> >
> >>I also have concerns about SCXML (its an xml
> >>spec, not a library).
> >
> > <snap/>
> >
> > I think its important to draw a distinction here. The SCXML
> > specification is within the realm of the W3C (its currently a Working
> > Draft), not Jakarta Commons. Commons SCXML is one possible
> > implementation of an SCXML engine, and will track the spec as it
> > evolves.
> I would view linkage to a W3C spec as a warning sign.

FWIW, the initial authors are fairly committed to getting this to a
point where it can flap its wings (its close, even today). I see your
point, but specs aren't well known sprinters either. Beyond the
initial thrust, if interest dies, we'll witness that. But maybe it
will fly. I'd like to know.

> > I'd say its very much a library, since the use cases for an SCXML
> > engine are multiple and varied. Anything that can be represented as a
> > UML state chart -- business process flows, view navigation bits,
> > interaction or dialog management, and many more -- can leverage an
> > existing SCXML engine library, which is what prompted the SCXML code
> > to move from the RDC Taglib to Commons Sandbox in the first place.
> I would also view the name as a warning sign. SCXML doesn't tell me
> about UML state charts.
> Think about lang, collections, beanutils, codec, id, logging ... all are
> very clear in their name as to what they do. They have very bland names
> often related to wrapping and enhancing a JDK area.

The new Jakarta sub-project is called Silk (which I've begun to like,
but have had multiple folks ask me "whats with the name?"). While
sometimes its worthwhile debating a name, its hard to please everyone.
In this case, the name goes with the spec.

> SCXML *may* fit more with the digester, betwixt, validator, group which
> are more focussed, almost mini applications/frameworks.
> Another way of looking at this is whether your API is broad but shallow,
> or narrow yet deep.
> - [lang] is broad (many API methods) but shallow (each piece of code is
> pretty isolated)
> - [betwixt] is narrow (very few main API methods) yet deep (each API
> method does a lot of work internally to achieve its goal).
> Personally I prefer the broad butshallow category, and am very wary of
> adding more of the narrow yet deep type to commons. A further discussion
> could be had over whether commons *could* be split along this division.

If you and others feel that way, then its surely a decision for
Commons to make. I understand that the broad but shallow category has
some lower thresholds, but useful Commons components come in either
category, and IMO, that would be quite a superfluous division,
possibly detrimental to the Commons community(ies).


> Stephen

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message