Return-Path: 
 <commons-dev-return-87472-apmail-jakarta-commons-dev-archive=jakarta.apache.org@jakarta.apache.org>
Delivered-To: apmail-jakarta-commons-dev-archive@www.apache.org
Received: (qmail 67074 invoked from network); 11 Apr 2006 01:45:43 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
  by minotaur.apache.org with SMTP; 11 Apr 2006 01:45:43 -0000
Received: (qmail 84101 invoked by uid 500); 11 Apr 2006 01:45:40 -0000
Delivered-To: apmail-jakarta-commons-dev-archive@jakarta.apache.org
Received: (qmail 84028 invoked by uid 500); 11 Apr 2006 01:45:40 -0000
Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:commons-dev-unsubscribe@jakarta.apache.org>
List-Help: <mailto:commons-dev-help@jakarta.apache.org>
List-Post: <mailto:commons-dev@jakarta.apache.org>
List-Id: "Jakarta Commons Developers List" <commons-dev.jakarta.apache.org>
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Delivered-To: mailing list commons-dev@jakarta.apache.org
Received: (qmail 84017 invoked by uid 99); 11 Apr 2006 01:45:40 -0000
Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 10 Apr 2006 18:45:40 -0700
X-ASF-Spam-Status: No, hits=-0.0 required=10.0
	tests=SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (asf.osuosl.org: domain of rahul.akolkar@gmail.com
 designates 64.233.166.182 as permitted sender)
Received: from [64.233.166.182] (HELO pproxy.gmail.com) (64.233.166.182)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 10 Apr 2006 18:45:39 -0700
Received: by pproxy.gmail.com with SMTP id t32so1216494pyc
        for <commons-dev@jakarta.apache.org>;
 Mon, 10 Apr 2006 18:45:18 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=GZp5IEe4yLunCa+YgM3IBZLj0Isr0JTh4hVRUJfGguOwKQ+mEW0kRx59UwInlbkiNyNzFuSSK61t0l1MJ9Nx20reto7XwLhTQesjIP1JKc6TEBULfyAQMFfXTDMUBwh/vRCo32uPxSkMnTM6eiQIHV9u/ZR3HvGoxx2I8p9v/vw=
Received: by 10.35.113.12 with SMTP id q12mr1709348pym;
        Mon, 10 Apr 2006 18:45:18 -0700 (PDT)
Received: by 10.35.40.1 with HTTP; Mon, 10 Apr 2006 18:45:18 -0700 (PDT)
Message-ID: <ce1f2ea80604101845o7f7bad44l64095c40d367c908@mail.gmail.com>
Date: Mon, 10 Apr 2006 21:45:18 -0400
From: "Rahul Akolkar" <rahul.akolkar@gmail.com>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Subject: Re: [VOTE] Promote SCXML to Proper
In-Reply-To: <443AD75D.1050001@btopenworld.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <ce1f2ea80604081445r2db4e644pf5c6ad841a7a757c@mail.gmail.com>
	 <1144702540.4389.54.camel@knossos.elmet>
	 <443AD75D.1050001@btopenworld.com>
X-Virus-Checked: Checked by ClamAV on apache.org
X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N

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