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> 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. > <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) When I was asked about a SCXML release, I replied in line with #2: http://marc.theaimsgroup.com/?l=jakarta-commons-dev&m=113511763426847&w=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. -Rahul --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
