shale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig McClanahan" <>
Subject Re: [dialog] Get rid of subdialogs
Date Thu, 24 Aug 2006 18:32:14 GMT
On 8/24/06, Sean Schofield <> wrote:
> > I'm not sure. I am somewhat uncomfortable adding new functionality when
> > there's already a valid mechanism in place, especially when such a
> change
> > requires considerable design changes. And in this case, we've got our
> hands
> > full of things that must be fixed for a viable dialog implementation
> that's
> > usable in production, such as supporting simultaneous dialogs. I'd
> rather
> > concentrate on those things first, hoping that the smaller issues, such
> as
> > this, will fall out in the design, if appropriate.
> It sounds like Craig is proposing a rapid redesign of the dialogs over
> the next few weeks.  If that's the case then IMO everything should be
> on the table.  Now that we've seen the limitations of shale dialog
> "out in the wild" its time to correct things now before its too late.
> I would agree that lots of the existing stuff is viable but it
> doesn't hurt to think out of the box before we commit ourselves to
> what we have.

In my ideal world scenario, we'll be able to rebuild things on the inside,
with minimal-to-none impact on how an application developer uses it.
However, I'm not convinced that goal is actually achievable, if we're going
to have a dialog infrastructure that meets the functional requirements we've
outlined.  Even if it is not totally possible, however, I'm a fan of the way
dialogs are currently configured, and would like to keep as much of that as
possible, even if we did something radical like used Commons SCXML as the
execution engine under the covers (betcha Rahul just perked up :-) -- things
like that should be on the table at this point, as far as I can see.

> david
> Sean


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message