commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rahul Akolkar <>
Subject Re: [SCXML] Decoupling Execution Context from the SCXML Model (WAS: [scxml] a few observations, issues before release)
Date Wed, 18 Jan 2006 23:54:33 GMT
On 1/18/06, Tim OBrien <> wrote:
> --- Rahul Akolkar <> wrote:
> > On 1/14/06, Tim OBrien <> wrote:
> > <snip/>
> > > 2. Decouple Execution Context from the SCXML Model
> > >
> <snip/>
> > Most of your observations are correct. We need effective cloneability
> > and/or decoupling, re-parsing is a waste. If you have any ideas, do
> > let me know. I'll spend some time on this during the rest of the week,
> > primarily just starting a new thread here, will clip the email length
> > in the next posts.
> >
> Created a place holder issue for the task of identifying the appropriate way to do this:
> Do you want to take a stab at this?  I had some ideas about the semantic impl, should
we both try
> out some ideas independently in two different branches and then see what bubbles out
> independent effort?

I will take a stab at this in the upcoming week or two, will post
something here when I get a chance to think some more about it. My
initial thoughts are not using Cloneable, rather having the SCXML
document read into a factory-style class, which can churn out
o.a.c.scxml.model.SCXML objects. WDYT? You're ofcourse welcome to try
an approach of your choice.

<sidebar>I just remembered one of your earlier comments about State's
not having a Context, but it appears there may soon be such an
association, lets wait on the next Working Draft for that.</sidebar>

Might work best to get ourselves branches, but *first* ...

Let us stabilize the package structure (will discuss this further in
the other thread about the package reorg). This might ensure we have
less headache when we try to fold in the branch(es) of choice. Given
your svn experience, maybe that isn't an issue, but can't hurt to
think the packages through before branching.

> > This actually was one of the things I had in mind between sandbox
> > graduation and release.
> >
> And, this is I guess one of the central issues with releasing scxml into commons (again,
not that
> I disagree with it being in the commons).  Althogh I think there is some room for flexibility
> after a release, commons components are limited by the fact that we haveto try to maintain
> compatibility between major releases.

I understand those constraints.

> Becuase of this, I think that the public interface of scxml needs extra scrutiny before
a release

Its welcome, and I'm thankful to anyone who offers the code such scrutiny.

> (and to me the 1.0 release happens at the same tie as promotion).

This is where there can be two schools of thought:

School of Thought #1:
Promotion == 1.0 (I was subscribed to this one in Taglibs, for
example, RDC went for 1.0 and promotion together)

School of Thought #2:
Promotion --> Bunch of RCs *and* potential changes --> 1.0
(gives earlier indication that development efforts are not going to /dev/null)

When I was asked about a SCXML release, I replied in line with #2:

I am not asking you (or anyone) to change their opinion, but the
ground reality in Commons today is #2, if we look at the recent
promotions -- components that are in proper but not at 1.0 yet (such
as vfs, resources) -- and their revision/BZ histories. Those are very
useful components, and make Commons all the more richer IMO (I looked
up the VFS RC with the intent to support it). They seem to follow the
second school of thought. I meant to take the same route for SCXML.
When in Rome ...

In the end what matters is the quality of the 1.0 artifacts, and both
approaches should get you that. Lets solve as many issues as we can
find while in sandbox, but based on what I can see around me, there is
some wiggle room after sandbox graduation and before 1.0, which is
where I was coming from.


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

View raw message