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?
Stefano.
-1 for this reason. As mentioned in other mails, direct access to the session isn't needed in Ugo's case.
+1 for a different reason: I think direct access to the session will be needed for backward compatibility with existing Cocoon components (e.g. Portal) that use the session for communication. But this could be encapsulated in a higher level JavaScript API that internally manages the session (like what I did with XMLForm). What do you think? Another possibility is to only expose the session at the Java level (not JavaScript) forcing new JavaScript objects that need access to it to be written in Java. This might prevent abuse.
Regards,
Chris
