On 8/24/06, Sean Schofield <[EMAIL PROTECTED]> 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
Craig
