[SCXML] Decoupling Execution Context from the SCXML Model (WAS: [scxml] a few observations, issues before release)

[Rahul Akolkar <ra...@gmail.com>]

On 1/14/06, Tim OBrien <to...@discursive.com> wrote:
<snip/>
> 2. Decouple Execution Context from the SCXML Model
>
> Right now, the Context passed into the class that parses the XML and creates the SCXML object is
> the global execution context.  You pass in a JexlContext when you are parsing the SCXML model, it
> is assigned to all of the State objects.
>
> So, bear with me, assume I have a SCXML document that represents the valid states of a stopwatch
> (ready, running, paused, stopped).  The SCXML models the watch in a way similar to the microwave
> sample in the Working Draft, it uses a reference to a "timer" variable.  To do this with the
> current implementation of SCXML, I would need to do the following twice (assuming a JexlContext):
>
>  a. Create a JexlContext
>  b. Populate the JexlContext with the appropriate variables
>  c. Call SCXMLDigester passing in the JexlEvaluator and the JexlContext I want to execute this
> state machine with
>  d. Create an instance of SCXMLExecutor, pass it the SCXML from step c.
>
> For each watch I need to model in this application, the implementation forces me to parse that
> SCXML document with Digester every time I want to model a separate StopWatch.  In the application
> I'm interested in using this in, hundreds of documents in a content management system are going to
> be modeled as individual state machines, I would hate to have to parse an SCXML file for each
> individual document.
>
> * Alternative: Provide a mechanism that allows you to clone an SCXML  instance so that you can
> create a separate SCXMLExecutor that can model the same statemachine with an isolated Context.
>
> * Better Alternative: States do not "have" a context.  Take the context property off of the State
> and change executeActionList in SCXMLSemanticsImpl to get the Context from the Executor.
> Likewise, Transitions do not have a "notificationRegistry", take that property off of a transition
> and just have the SCXMLSemanticsImpl get the notificationRegistry from the Executor.
>
> I don't think this is a terribly difficult idea, and decoupling the description of the FSM from
> the execution state, would also make it much easier to persist either one.
>
<snap/>

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.

This actually was one of the things I had in mind between sandbox
graduation and release.

-Rahul

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [SCXML] Decoupling Execution Context from the SCXML Model (WAS: [scxml] a few observations, issues before release)

[Rahul Akolkar <ra...@gmail.com>]

On 1/19/06, Tim OBrien <to...@discursive.com> wrote:
>
<snip/>
>
> 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.
>
<snap/>

My previous post didn't come out right, this "decoupling" is ofcourse
needed in the current implementation, which is why this thread exists
:-)

In terms of feedback to the WG, there are public mailing lists at the
W3C per WG where feedback can be posted, though I doubt they need any
convincing on this aspect. And for better participation, we should
push here on making the ASF a member as well.

-Rahul

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [SCXML] Decoupling Execution Context from the SCXML Model (WAS: [scxml] a few observations, issues before release)

[Rahul Akolkar <ra...@gmail.com>]

On 1/18/06, Rahul Akolkar <ra...@gmail.com> wrote:
> On 1/18/06, Tim OBrien <to...@discursive.com> wrote:
<snip/>
> >
> > 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.
<snap/>

Made some progress on this over the weekend, just published the site
with proposed changes which might make it easier (for instance, to
compare Javadocs):

http://people.apache.org/~rahul/sites/scxml-stateless-model/

Once the model is free of "state" (thats a highly overloaded term in
this context), the digester / reader API is freed of Contexts and
Evaluators (as it should be - thereby allowing the model to be reused
or concurrently used by many executors). To summarize the changes, I'd
compare:

http://people.apache.org/~rahul/sites/scxml-stateless-model/api-notes/core-digester.html

with:

http://jakarta.apache.org/commons/sandbox/scxml/api-notes/core-digester.html

-Rahul

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [SCXML] Decoupling Execution Context from the SCXML Model (WAS: [scxml] a few observations, issues before release)

[Tim OBrien <to...@discursive.com>]

--- Rahul Akolkar <ra...@gmail.com> wrote:

> On 1/18/06, Tim OBrien <to...@discursive.com> wrote:
> >
> >
> > --- Rahul Akolkar <ra...@gmail.com> wrote:
> >
> > > On 1/14/06, Tim OBrien <to...@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

Re: [SCXML] Decoupling Execution Context from the SCXML Model (WAS: [scxml] a few observations, issues before release)

[Rahul Akolkar <ra...@gmail.com>]

On 1/18/06, Tim OBrien <to...@discursive.com> wrote:
>
>
> --- Rahul Akolkar <ra...@gmail.com> wrote:
>
> > On 1/14/06, Tim OBrien <to...@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>

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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [SCXML] Decoupling Execution Context from the SCXML Model (WAS: [scxml] a few observations, issues before release)

[Tim OBrien <to...@discursive.com>]

--- Rahul Akolkar <ra...@gmail.com> wrote:

> On 1/14/06, Tim OBrien <to...@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?

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

Becuase of this, I think that the public interface of scxml needs extra scrutiny before a release
(and to me the 1.0 release happens at the same tie as promotion).

> -Rahul
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org