On 17/6/03 22:51, "Stefano Mazzocchi" <[EMAIL PROTECTED]> wrote:
- Should the flow _always_ be associated with a Session?
I haven't written a flowscript that didn't require, in some way or another, the availability of some statefulness on data and it seems to me as overkill to use full execution state preserving (and the URI-encoding of the continuation every time!) just for the data (besides, even today, if you want to keep global flow variables around, you have to enable sessions anyway)
In general, it is true that continuations and sessions are different beasts, but in real life, continuations *extend* sessions since they provide the ability to save *even more* state than sessions.
But in those situations where procedular flow is weak and navigation decisions are driven by user action and not by flow execution, continuations are overkill and sessions are still the preferred way to go.
is there a real need for continuations without sessions? i really can't provide a meaningful example of this.
so, I would say +1 to this.
if you are against this, please speak up now.
Pinching in at the last minute, as I'm completely overswamped by work at this time (writing a template engine, u know, can be hard)...
We've got some _serious_ problems with sessions lately at VNU. The problem we faced is that in 99.9% of the containers out there sessions, by containers, are identified uniquely with a cookie stored on the client side.
What does that mean? That no matter how many browser windows you have open, your client will uniquely be identified by the server as "one".
Our problem lies in the multitasking ability of one client, so to say, to be able to continue two instances of the same flow at once.
We have a "registration centre", where people can mail (snail mail) and phone in to subscribe for VNU's different magazine offering.
Let's take this example: one of our kids at the registration centre is entering the details for one subscriber, whose information he got through the post, she has a card in front of her, and goes through several web pages (a some sort of "flow") to enter (or rather copy) the user registration card.
At the same point in time, the same person gets a call on the phone, he/she needs to follow the SAME EXACT FLOW, but in a different "instance" (pausing the "card-based" registration, and doing the same thing but asking the details from the guy on the phone).
Now, if my "flow" is somehow stored in the session, which is stored in a cookie, the "card" registration details, and the "phone" registration details get messed up, as the server has no way to figure out that the same client (identified by a cookie) is doing two "instances" of the same thing at the same time.
We solved this by switching our servlet container to Jetty, which has a nice feature "forcing" itself to completely ignore cookies and by URL-rewriting every link and form action. By forcing this, we now have the opportunity to have uniquely identified "per-task" based sessions (based on URL-rewrites), rather than a global "per-client" session.
Given the current implementation of sessions on servlet containers, it's so easy to F-word-UP is the client opens a new window and tries to do something different (the client will either completely ZERO whatever task he/she is doing, or mix up the session data), unless you don't force URL-rewriting-with-cookie-ignoring (which AFAIK can be done only w/ Jetty).
Think about a continuation like an instance of a "task" stored on the server, while unfortunately you have to realize that a session is the instance of a "client" (with all its tasks) on the server.
Kinda like multiplexing, multiple tasks on the client, multiple tasks on the server, only ONE and only ONE (in most cases) session between the client and the server...
Just my 0.02 GBP/Euro/USD (depending on whatever country you're in)
Pier, unless I'm mistaken, it seems your problem can be solved with the flow without hacking sessions.
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 ?
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
