commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rahul Akolkar" <rahul.akol...@gmail.com>
Subject Re: [VOTE] Promote SCXML to Proper
Date Tue, 11 Apr 2006 01:45:18 GMT
On 4/10/06, Stephen Colebourne <scolebourne@btopenworld.com> wrote:
> Oh, this is a tough one...
>
> [scxml] has user interest, what looks like a good codebase, excellent
> documentation. The problem is that it really doesn't quite seem to
> belong in commons. But equally it doesn't really belong obviously
> anywhere else at the moment*
>
<snap/>

I thought long about this, before calling this VOTE. Personally, I'm
convinced this is a good thing to do. If you look at this in terms of
a game theory problem where the players are ...

 * The community currently interested in this codebase
 * The individuals and OSS projects that may benefit from this
codebase (in future)
 * Our own desires, preferences, and notions of ideal embodiment of a
Commons component
 * And probably least importantly, the actual code itself

... I think there is a chance that you may come to realize, as I have,
that this is in fact the Nash equilibrium.


> Three specific things:
> - the name - commons-state or commons-statechart reads better to me than
> commons-scxml
>
<snip/>

I think we talked about this at the proposal stage as well, changing
the name right now probably means:

 * More confusion to users
 * More needless renaming in SVN
 * Departure from the fact that this specifically is an engine based
on the W3C SCXML WD.

But if the majority of us here want to rename the component, I'm not
wedded to the name either.


> - library-ness - if this were a library that assisted with state
> handling, with an optional ability to read from the scxml format, then
> that might fit better with a commons library style component
>
<snap/>

This was actually discussed on the user list a couple of days ago --
using the engine by procedurally building up the in-memory Commons
SCXML object model for the state machine. The SCXML IO should probably
never be "optional", but there could be a well-publicized purely
API-based end-to-end approach. If this aspect interests you enough,
please file an enhancement request in bugzilla so this doesn't get
forgotten.


> - number of packages - [scxml] already has 10 packages (I know there's
> not much in many, but the concepts exist). I think this could be
> considered a warning sign (in the same way that a facination with the
> Apache brand is a warning sign for the incubator). IMHO, the better
> commons components are those with few packages. Perhaps, this is really
> more of a scope expansion warning.
>
<snip/>

I understand, and it is a valid point. As Robert has said, the scope
needs to be well-defined and constrained, the engine needs to remain
"lightweight". However, in terms of the packages you point to, this is
not at all different from how [chain] has {web,faces,portlet,servlet}
packages. FWIW, I consider [chain] to be a better Commons component.


> My vote has to be -0.
>
<snap/>

Thanks for voting. Personally, I'd rather prefer if it were a "I'm
fine with it" rather than "I'm not too keen", so if anything changes
your mind, feel free to revote. I respect your opinion as-is
regardless.

-Rahul


> Stephen
>
>
> *This vote is also linked in my mind with the ongoing discussions about
> jakarta's future. If the difference between commons-level and
> jakarta-level disappears then new scopes will appear within jakarta and
> scxml will probably find a home more easily.
>
> >>------------------------------------------------------------------
> >>[ ] +1 Move [scxml] to Commons Proper
> >>[ ] +0 I am fine with this move
> >>[X] -0 I am not too keen, because ...
> >>[ ] -1 I am against this move, because ...
> >>------------------------------------------------------------------
>
<snip/>

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