commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim OBrien <tobr...@discursive.com>
Subject Re: [SCXML] Decoupling Execution Context from the SCXML Model (WAS: [scxml] a few observations, issues before release)
Date Thu, 19 Jan 2006 15:41:35 GMT


--- Rahul Akolkar <rahul.akolkar@gmail.com> wrote:

> On 1/18/06, Tim OBrien <tobrien@discursive.com> wrote:
> >
> >
> > --- Rahul Akolkar <rahul.akolkar@gmail.com> wrote:
> >
> > > On 1/14/06, Tim OBrien <tobrien@discursive.com> 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:
> > http://issues.apache.org/bugzilla/show_bug.cgi?id=38311
> >
> > 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 of
> > independent effort?
> >
> <snip/>
> 
> 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>
> 

Even if a state is associated with a context it doesn't necessary mean that there needs to
be a
relationship with an actual context item.

I guess this is a case of "well....wouldn't it be helpful to be able to participate in that
Working Group".  :-)

The thing that I think is important for the SCXML working group to know is that for some
applications to be feasible a state machine must be efficient, not tied to execution context
and
able to be shared at runtime by "possibly" thousands of instances.  Maybe putting it in Voice
terms might make it more relevant to that specific working group, if I'm trying to model the
state
of ten thousand simultaneous conversations, I'd start to care whether or not I'd would have
to
replicate the entire model or representation of the state machine.  

> > > 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.
> >
> <snap/>
> 
> I understand those constraints.
> 
> 
> > Becuase of this, I think that the public interface of scxml needs extra scrutiny
before a
> release
> <snip/>
> 
> 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).
> >
> <snap/>
> 
> 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)
> 

I prefer #1 because it provides some motivation for interested developers.  To me it ensure
that
there is a community around something before promotion rather than jsut promoting something
that
would ultimate get abandoned (like feedparser which IMO was promoted without much scrutiny).

But, that's neither here nor there, I don't think scxml will have an issue getting to a 1.0
release.

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