I am somehow aware that I am abusing sessions here, and that there is a better way, but it's not that easy to follow, probably. If you can show it to me, I'd be glad to abandon sessions, but if you take them away right now, I'm going to be in trouble ;-).
Great, integration between different not-all-flowable parts is a *real* need for sessions in the FOM.
So +1 to add it.
Anybody against it?
I haven't had anything to say in this discussion so far, but somehow this deserves a comment...
It would seem a shame to me to include sessions purely for 'inter-flow' communication. Given the thorough way you are all thinking about this, it seems a bit of a cop-out solution to just add sessions back in.
Why is it a "shame"?
Surely what Ugo needs is the ability to 'modularise' a single flow, in a way that makes it managable? Then you've got one flow (which is all I would say a single application should have, because there's just one interaction with a user), which removes the necessity for sessions (which would be very good), but still allows Ugo to manage a number of different routes through that flow, in an easily managable way.
I've no idea how achievable that would be, as I've never played with flow myself, but just adding sessions back in seems like a major opportunity missed.
Continuations are used when you have a sequence of related pages, in that case the application state can be stored in local variables within the Continuation. When you simply have "jumps" to other pages, in the flow that is modeled by "top-level" function calls. The top-level functions are still part of the same application and share state, however. This is handled in the flow by storing the shared state in javascript global variables, e.g. in Ugo's example:
var user;
function login(username) {
cocoon.createSession();
user = UserManager.getUser(username);
sendPage("User.html", user);
}function chpasswd(newpasswd) {
user.password = newpasswd;
user.store();
sendPage("User.html", user);
}