[Zope] Session Management

[Pavlos Christoforou]

On Wed, 5 Jan 2000, Anthony Baxter wrote:

> temporary variables in the object'. The rationale behind having 
> REQUEST.SESSION was to make it behave in a way similar to RESPONSE. 
> I explicitly did _not_ want to have session variables automatically
> looked up, or stored - this seemed to me to be an error prone way to
> go. I also dislike things that stomp all over my global namespace,
> and pulling all session values out seemed too much like 'from foo import *'
> to me.

There is no global namespace pollution really. FSSession stores all
session info in a mapping object that does not participate in Zope's
transaction machinery. When FSSession is initially called the mapping
object is populated with the session info, which can be accessed like:
<dtml-var "FSSession['info']">.
At the end of the request, if any session data were modified/added then
the mapping object is marshalled back on the filesystem. Thus all the
session info is only visible through the FSSession object and its methods,
and changes are stored only once, at the end of a succesful request.

The reason I chose this approach over the SQLSession one is that this
allows one to get away with having to call the Session management object
before it can be used. Even though FSSession now requires one to call
FSSession initially, the mapping object methods can be rewritten to check
whether the session info has been loaded or not and act accordingly, thus
eliminating the need to call the session object first.
> 
> > > 
> > > SESSION API:
> > >    SESSION.getName() - returns the session id of the current session.
> > Ok I will add it. Right now the SessionUID is inserted in the REQUEST
> > object.
> 
> I could add that as well, I guess - but I prefer having all of the session
> values inside REQUEST.SESSION. 

Agreed. All the session values are in FSSession but the Session ID is used
often enough and having it in the REQUEST object makes things more
convenient. I prefer typing:
<dtml-var SessionUID> rather than <dtl-var "FSSession['SessionUID']">. No
big deal really. I can remove it if you think is unneccessary.


> 
> Hm - I've thought about this, but haven't come up with an authoritative
> (if that's the right term) way to deal with it. One way I've thought to
> do it is to make the first form submit have a hidden field called something
> like '_this_form_should_send_in_a_cookie_called_foo', then check the next
> page for a cookie called 'foo'. If it's not there, stuff 'foo' into the URL.
> 
> I'd like to avoid putting the session in the URL by default, tho.

This is mainly a convenience function (PHP session manager includes
something similar I believe). It was requested by a Zopista so I added
it. It is not really meant to be used as the default method. Most of the
times the programer will decide explicitly how to pass the sessionID
around.

Mashal vs cPickle ...

My tests show that for a fairly complex structure marshal is roughly 2x
faster than cPickle in dumping objects and 3x in loading objects. I
figured in the rare cases that one needs to store more complex structures
than marshal supports, one can use a simple external method that
takes an object as an argument and returns the pickled string.

And I will agree with you that an easy way to inspect session info is
nice. My approach is to include a simple utility with the distribution
that can pretty print session info from the command line. I wouldn't want
to use a less efficient internal represenation though.

What do you think?

Pavlos