cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Jellinghaus <>
Subject continuation fear (was Re: [status & RT] design challenges)
Date Tue, 09 Apr 2002 01:38:48 GMT
At 10:25 AM 4/7/2002 -0500, Ivelin Ivanov wrote:
>From: "Ovidiu Predescu" <>
>To: "Ivelin Ivanov" <>
>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:
> >
> >
> > 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.

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

2) Continuations are difficult to evaluate for performance.  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.

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

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 :-)


To unsubscribe, e-mail:
For additional commands, email:

View raw message