commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Colebourne <scolebou...@btopenworld.com>
Subject Re: [SCXML] Suitability as a Commons project (Was: Moving to commons proper)
Date Thu, 08 Sep 2005 22:23:49 GMT
Rahul Akolkar wrote:
> As I return from big sky country, I see this probably warrants its own thread -
> 
> On 9/4/05, Stephen Colebourne <scolebourne@btopenworld.com> 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.


> 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.

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.

Stephen

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


Mime
View raw message