"Sylvain Wallez" <[EMAIL PROTECTED]> 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
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects } Orixo, the opensource XML business alliance - http://www.orixo.com
