cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <>
Subject Re: [RT] flow machinery
Date Wed, 26 Oct 2005 15:41:02 GMT

Sylvain Wallez wrote:
> Torsten Curdt wrote:
>> Gang,
>> there are a few things regarding the current flow machinery that
>> are bugging me for quite a while now. In order to support flow
>> serialization they need to be addressed.
>> 1. Class vs Interface
>> The WebContinuation is currently a class. IMO it makes much more
>> sense to turn it into an interface an have the individual "FlowEngine"
>> implementation act as a factory. That way javaflow could create
>> WebContinuations that implement Serializable.
> +1.


>> 2. Naming
>> The name JavaInterpreter just misses the point. I would like to
>> rename the "Interpreter" interface to something like "FlowEngine".
>> Other suggestions are welcome.
> +1 as well. I even proposed it 2 years ago [1] ;-)

+1, I remember :-)

and find that the old doc (at new URL:, ever so unreadable as
back then) still holds some ideas worth considering, no?

for one: the possibility to have more then one 'flowEngine' as you call
it available inside one sitemap would be neat

(and there were some more related re-naming suggestions for the sitemap
syntax as well IIRC, maybe the future of a 2.2 release offers us the
fork to concider some of that as well?)

>> 3. Continuation Management
>> When it comes down to serialization of flow there are 2 aspects.
>> One is flow persistence and the other one is flow replication
>> across machines.
>> In order support flow persistence we would need the make the
>> ContinuationManager save and reload serializable continuations.
>> ...which is not big deal. Unfortunately replication is a slightly
>> different subject.
>> The distributed ContinuationManagers would need to synchronize
>> the continuation trees across the network or at least find a way
>> to direct to the appropriate server that holds the continuation.
>> TBH ...I am not eager to re-invent the wheel here. In fact this
>> whole machinery is already in place for sessions. Why not re-use it?
>> In fact I don't really see a big point of having web continuations
>> without sessions anyway.
> +1 again. There aren't many real use cases where continuations span
> several sessions. And being tied to session may be one of the
> constraints/requirements to use clustered continuations.

I was glad enough to hear Torsten make his point on this IRL during
drink/reception of this year's gettogether...

>From a pure web/REST/temp resource POV I still like the idea of having
dynamic URI's that can be shared between end users (thus regardless of
their session) is kinda cool (think chatrooms/operators assisting in
'your' flow), but I think this kind of use could also be solved by smart
redirects and some application level 'resource' management (probably be
even safer then just having it de facto available)

>> Assuming the continuations are stored inside the session, storing
>> and restoring the sessions would take care of the persistence.
>> Directing to the server with the right session also assures to
>> get to the right cocoon instance running the right ContinuationManager.

And this nice explanation shows IMHO enough pragmatic bonusses...

so +1

> Yup. This is required also for load balancing.
>> Flow replication itself should then also be solved by session
>> replication without any further effort. The only open question
>> is the continuation expiry mechanism. It might be good enough to
>> just run the expiry on every machine ...I am wondering how that
>> might affect the replication though.
> Looks like HttpSessionActivationListener can by our friend here, as it
> allows session attributes to be notified when a session is passivated
> and activated.
> Sylvain
> [1]

Marc Portier                  
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at                          

View raw message