cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: Experience with workflow at Hippo Webworks
Date Sun, 07 Mar 2004 02:26:43 GMT
Guido Casper wrote:

> Stefano Mazzocchi wrote:

>> If FSM work bad for flow, why would they work any better for workflow?
> After thinking again about ways to use continuations with workflow I
> came to the conclusion this might well be possible. But it looks awkward
> to me.
> Each document attached to workflow would need a workflow instance as
> long as the document lives (from creation to deletion). This would mean
> the continuation stack of every document needs to be persisted to - well
> - to a database if you don't want to limit your clustering options. The
> document has a property holding the continuation ID.

You have a point here, Guido. It is true that continuations in a 
distributed environment would need to be made custer-friendly and 
replicated. This would probably impact the overall performance... but 
keep in mind that continuations are just another way to save state. That 
kind of state transformation (think REST) will have to be done anyway.

> Requests for putting a document into another state now simply means (how
> simple that really is I have no idea as I'm not familiar with the
> details of Rhino or continuations) getting the continuation stack
> belonging to the document's continuation ID from the database and resume
> processing.
> Besides the hassle to maintain the continuation stacks in a database 
> there is another drawback IMHO.
> Now that I'm able to describe my workflow in a Javascript, how might
> that script look like?

Yes, I've been thinking about this myself too. No matter what, I'm 
always scared by the complexity that FSM normally reach, especially if 
they are maintained by more people overtime.

> No matter how hard I think about it, it seems I'm unable to come up with
> a piece of code that looks simpler than what I have without continuations.

Interesting. would you like to share that with us? I think it would be 
avery good exercise to see the two approaches one beside the other.

> Continuations within a webapps are better than a FSMs because the FSM
> approach is just a workaround for the lack of a single-threaded view of
> my webapp and continuations brought back that view to me. However for
> potentially everlasting conditional (and rather detached) workflow state 
> transistions FSMs do not look like a workaround to me but like the (or 
> one) solution.

I still don't see that, but, admittedly, my experience with complex 
workflows is limited. But I think it would be a great exercise, as I 
said, to try to describe a natural situation in both ways and see which 
one is easier to grasp or feels more natural to people.

> Page flow control mostly is rather small pieces of potentially complex
> conditional logic with few branches (the user "is passively guided"
> through the page flow) while workflow logic looks like an everlasting
> loop of simple conditional logic with potentially lots of branches (the 
> user "actively triggers" the workflow).

I really don't think you can draw a line that easily, but I do see your 

I think it's better to work on a few example of what this might look 
like in the two scenarios (FSM or javascript+continuations) and see what 
happens. WDYT?


View raw message