shale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sean Schofield" <sean.schofi...@gmail.com>
Subject Re: [dialog] Submachines, Contexts and Shale subdialogs (was Re: Get rid of subdialogs)
Date Fri, 25 Aug 2006 01:18:45 GMT
My main point in suggesting we "scrap" subdialogs is that we stop
treating them in the manner that Rahul is describing (as GOSUB
approach.)  If we eliminate this stack approach to the context then
everyone is happier and I think we'd all be in 100% agreement.

The question is the best approach to do that.  The idea of injecting
the state was just off the top of my head.  The SCXML sounds better
but I don't know anything about SCXML and haven't read Rahul's post on
that yet.

Sean

On 8/24/06, Rahul Akolkar <rahul.akolkar@gmail.com> wrote:
> On 8/24/06, Craig McClanahan <craigmcc@apache.org> wrote:
> > On 8/24/06, Rahul Akolkar <rahul.akolkar@gmail.com> wrote:
> > >
> > > [snip]
> > > Which brings us to the discussion about sharing "dialog data" as-in
> > > SHALE-153, and this is where Shale subdialogs deviate from most
> > > dialects of state chart theory, where submachine states are not
> > > processed according to the stack-based GOSUB approach WRT state
> > > contexts. A submachine state is meant to be "syntactic sugar" and
> > > should not have any difference in (runtime) semantics as compared to
> > > inlining the submachine into the parent state machine. And that tends
> > > to blow away any concerns about sharing data / communicating across
> > > parent-child (sub)dialogs.
> > >
> > > i.e. if foo.scxml from the snippet above pointed to this degenerate
> > > machine:
> > >
> > > <scxml initialstate="end">
> > > <state id="end" final="true" />
> > > </scxml>
> > >
> > > the original state above may be replaced by the following:
> > >
> > > <state id="foo" ...>
> > > <initial>
> > >   <transition target="end"/>
> > > </initial>
> > >
> > > <state id="end" final="true" />
> > > ...
> > > </state>
> > >
> > > for identical behavior. Commons SCXML will "crawl" to the src URL,
> > > grab the state machine from foo.scxml, parse and incorporate it into
> > > the parent state machine as the state holding the src attribute. The
> > > "root context" of foo.scxml then becomes the context for the state
> > > with id "foo".
> >
> >
> > So, to see if I'm getting it yet, are the following statements an accurate
> > representation of what you're describing?
> >
> > * SCXML achieves reuse by essentially "inlining" a previously
> >   configured set of descriptions into the current one; and
> >
> > * When that happens, there is only one "context" instead of the
> >   stack that Shale Dialog currently creates when you use
> >   a subdialog.
> >
> <snip/>
>
> Correct (one root context, thats a quibble about hierachial / per
> state contexts -- only applicable if each state can have its own
> "namespace" -- IIRC, not in the current Shale dialog notation).
>
> The end result is one state machine. Thereby, I can "decorate" the
> subdialog with a transition that points to a state in the parent
> dialog (often the thing that hampers reuse is the inability to
> incorporate the subdialog effectively because it cannot "see" the
> view/action states in the parent dialog if its a completely new state
> machine).
>
> -Rahul
>
>
> > -Rahul
> > >
> >
> >
> > Craig
> >
> >
>

Mime
View raw message