cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [vote results] FOM
Date Thu, 19 Jun 2003 09:55:43 GMT
Pier Fumagalli wrote:

>"Sylvain Wallez" <> wrote:
>>Pier, unless I'm mistaken, it seems your problem can be solved with the
>>flow without hacking sessions.
>Indeed... But Stefano asked "Should the flow _always_ be associated with a
>Session?", which I assumed (maybe prematurely) as a one-to-one mapping
>between session and flow, therefore reducing the number of flows in
>execution by the client, as we have only one session...

Ah, I understand... that there's a misunderstanding here ;-)

The word "flow" in Stefano's quote actually means "global variables of 
flow scripts". But local variables of different instances of a flow 
(i.e. the continuation trees started by a <map:call function>) are in 
different spaces and don't conflict.

>>A continuation tree is actually the "flow instance" you're talking
>>about. So you can have different flow instances running concurrently
>>smoothly, provided that their state is only stored in local variables.
>>Global variables should be used to represent state that is
>>user-dependent but not flow-dependent.
>>What do you think ?
>I'm fine w/ it, as long as the continuation ID is never stored in the session, but rather
always URL encoded in the generated output...
>That's the only thing I'm _really_ concerned about...

Some people asked in the past why continuations ID had to be transmitted 
through URL rewriting or request params and couldn't be stored in 
cookies. The answer was exactly about the problem you mention above : a 
cookie, as the session, are unique for a given browser, and this is not 
suitable to store a continuation id which identifies both a flow 
instance and a location in that flow instance.

Hope this makes things clearer.


Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -

View raw message