[Zope] Session Management

[Anthony Baxter]

>>> Pavlos Christoforou wrote
> 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']">.

Ah - so rather than calling the session object, then looking up in
REQUEST.SESSION, you just look up in the session object?

Would it be possible to support both of these methods of operation?
If you call the session object, it creates REQUEST.SESSION. If you
call it's __getitem__ type methods, it does it directly. 

> 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.

*nod* ok, so you're only doing a single write? This is something I intend
to fix in SQLSession, somehow - all changes to the session only get sent
to the DB at the end, rather than straight away, as now. This means that 
if a value is changed 10 times during a request, 10 delete/inserts will
happen. Fixing this safely is hard, and it's not something that's causing
me a lot of problems right now, so I'm not too worried about it.

> 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.

I always put the call to the session object in my standard_html_header,
so this isn't a problem. I'd _like_ to think that some time in the future
there'll be some sort of session support bolted into the core of Zope, so
that the session gets automatically called. 

(I tried using a 4am access rule, but this played badly with things - in
particular, it shredded the management interface.)

> 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.

Fair enough - I'm suprised that it's getting used that much, I only added
SESSION.getName() in the last release (there'd been no requests for it
before then). Is this for the session-in-url thing?

> > [ url() method ]

> 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.

Fair enough, I guess.

> 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.

I originally looked at marshal - but one of the earlier things I wanted
to cache in a session was the result of an sql method. therefore I went
with pickle over marshal. I'm also not convinced that the pickle/marshal
difference isn't going to just be miniscule compared to the time to pull
the session data off disk, or out of a DB - in general we're talking 
really small things.

> 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.

I was thinking about making it an option - that way, if you wanted to
write an SQL process that went through the DB looking for objects that
match a particular attr=value, you don't have to deal with decoding the
objects yourself. It's no biggie for me right now, though, so unless 
someone submits a patch, it will stay on the todo list.

Anthony

-- 
Anthony Baxter     <anthony@interlink.com.au>   
It's never too late to have a happy childhood.