--- Rahul Akolkar <[EMAIL PROTECTED]> wrote:
> On 1/18/06, Tim OBrien <[EMAIL PROTECTED]> wrote: > > > > > > --- Rahul Akolkar <[EMAIL PROTECTED]> wrote: > > > > > On 1/14/06, Tim OBrien <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
