Re: continuation fear (was Re: [status & RT] design challenges)

[Ovidiu Predescu <ov...@apache.org>]

On Mon, 08 Apr 2002 17:38:48 -0800, Rob Jellinghaus <ro...@unrealities.com> wrote:

> At 10:25 AM 4/7/2002 -0500, Ivelin Ivanov wrote:
> >From: "Ovidiu Predescu" <ov...@apache.org>
> >To: "Ivelin Ivanov" <iv...@apache.org>
> >Sent: Friday, April 05, 2002 10:33 PM
> > > Workflow's approach appears to be based on a finite state machine
> > > model. Checkout the sample control file at:
> > >
> >http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/workflow/src/wizard-de
> >mo/WEB-INF/wizard.xml?rev=1.1&content-type=text/vnd.viewcvs-markup
> > >
> > > The same approach can be modeled in Cocoon today using actions.
> 
> Does anyone have an example of this?  The current action example (the 
> standard sample webapp) is fairly sketchy, and it's not clear how to do a 
> more complex workflow.

I don't think you'll find such an explicit example today.

> > > However a much better approach is the one based on
> > > continuations. Check out the Schecoon calculator sample at:
> >
> >I have actually seen it and was hoping that you can elaborate a bit on the
> >advantages of continuations vs. state machine.
> 
> I agree.  Also, I'm fairly concerned by two things:
> 
> 1) Continuations are notoriously difficult to understand; building them as 
> the fundamental (and, if I understand Stefano's predilections, *only!*) 
> mechanism of webapp flow control is going to do some damage to Cocoon's 
> comprehensibility.

In Schecoon you don't deal with continuations directly, they're hidden
under the cover. The only thing you see is a sendPage() function,
which sends the response page and interrupts the processing, only to
resume it later when the following request comes along.

> 2) Continuations are difficult to evaluate for performance. 

This is a correct statement.

> A procedural model, with explicit webapp state management, at least
> makes it clear to the programmer how much state is being kept by
> their webapp, and gives them more or less full control over tuning
> that state.  A continuation mechanism could radically change the
> amount of retained state (consider the possibility of inadvertent
> variable capture of large data structures by a continuation stack!).
> And it might or might not be *possible* for the end programmer to
> fix those capture issues.

I hope the rules that define what gets into a continuation and what
not, will be very clearly documented. It should be simple for the end
user programmer to fix these issues by assigning these variables the
null value before capturing a continuation.

I'm also investigating some optimizations in the Rhino implementation,
that could eliminate capturing temporary variables in continuations.

> Perhaps Ovidiu's proposed uses of continuations are elegant enough, or the 
> current scripting/continuation-capture mechanism is efficient and minimal 
> enough, to address both these concerns.

The usage of the framework is fairly simple, and the notion of
continuation is not exposed explicitly when you're doing programming
as end user programmer.

The scripting languages supported should know how to deal with
continuations explicitly, Schecoon/Cocoon cannot help in any way in
how they implement things.

> But personally I would very much hope that the flowmap mechanism
> allows (not requires, but allows) a more procedural style as well,
> with explicit state management.

My original Scheme-based implementation had continuations support
only, and no actions support was planned. The second implementation,
which is the current one, is much more tightly coupled with Cocoon, so
you can make use of all the other features you're used to from Cocoon.

> You do not need to listen to me very closely, however, as I am under
> enough time pressure with my current project (constructing a fairly
> complex multi-page form-based issue tracking system) to drive me to
> work with Struts instead.  It's a shame, as Cocoon seems more like
> the right thing, but I don't have time to struggle with the
> documentation (or lack thereof), or to wait for Schecoon to mature
> into something straightforwards.  I hope this changes in the very
> near future (i.e. I hope Cocoon/Schecoon get better documentation &
> examples, or I get more time, or both :-)

I certainly hope Cocoon will change for the better in the very near
future.

Greetings,
-- 
Ovidiu Predescu <ov...@apache.org>
http://www.geocities.com/SiliconValley/Monitor/7464/ (GNU, Emacs, other stuff)

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: continuation fear (was Re: [status & RT] design challenges)

[giacomo <gi...@apache.org>]

On Mon, 8 Apr 2002, Ovidiu Predescu wrote:

> On Mon, 08 Apr 2002 17:38:48 -0800, Rob Jellinghaus <ro...@unrealities.com> wrote:
>
> > At 10:25 AM 4/7/2002 -0500, Ivelin Ivanov wrote:
> > >From: "Ovidiu Predescu" <ov...@apache.org>
> > >To: "Ivelin Ivanov" <iv...@apache.org>
> > >Sent: Friday, April 05, 2002 10:33 PM
> > > > Workflow's approach appears to be based on a finite state machine
> > > > model. Checkout the sample control file at:
> > > >
> > >http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/workflow/src/wizard-de
> > >mo/WEB-INF/wizard.xml?rev=1.1&content-type=text/vnd.viewcvs-markup
> > > >
> > > > The same approach can be modeled in Cocoon today using actions.
> >
> > Does anyone have an example of this?  The current action example (the
> > standard sample webapp) is fairly sketchy, and it's not clear how to do a
> > more complex workflow.
>
> I don't think you'll find such an explicit example today.

Have a look at the thread
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=100322680410605&w=2

Giacomo



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org