[Zope] Sessions needed

[michel@digicool.com]

Frank Buhr <buhr@kogs1.informatik.uni-hamburg.de> writes:

> Hi,
> 
> after doing some experiments with Zope I'm still missing an important feature:
> 
>    How can I easily keep state information over several HTTP-Requests?
> 
> The abstraction that provides this is called "session" for instance in the Java Servlet API
> http://java.sun.com/products/servlet/2.1/html/api-reference.fm.html#945
> JS-sessions provide an abstraction from cookie-mechanisms or URL encoding.
> 
> Netscapes server side javascript provides similar things. There are some
> choices for the implementation of sessions: keeping state information 
> on the server (the client only references an ID) or on the client 
> (all values are stored on the client), using cookies, URL encoding or 
> hidden form elements.
> 
> I found some Classes in the Zope sources where there is already state information
> maintained by cookies (TreeTag and ZRDB.DA)
> This seems to be equivalent to the combination "data on the client, use cookies" from above.
> 
> I very much like the idea of separating the service of "state keeping" from
> the concrete implementation (which might even be chosen dynamically according
> to browser capabilities or user preferences ("no cookies -> use URL encoding")
> 
>    Did I overlook something or is there really no session _abstraction_ in Zope?

You are correct, there is no low level session abstraction in Zope.
This problem is much thornier than it sounds.  Attempting to have a
both useable and flexable session toolkit has show to us to be a
difficult concept that requires a lot of thought.

What are generally called 'sessions' is actually a smaller piece of a
much larger puzzle we call 'membership'.  More than just a private
namespace for a series of HTTP transactions, membership is more of a
concept of 'meta-sessions', keeping state between a series of sessions.
There are, actually, only a small number of scenarios where
construction and destruction of 'sessions' is useful unless the
information on the user of that sessions is kept for later sessions.

Everyone and their brother has a gazzillion custom requirements they
need satified in this very vague (and ill-defined by the JS standard)
area we call membership.  The actualy 'session' part (which we use a
cookie to solve) is one of the easiest pieces of the puzzle.  Although
many other toolkits have the ability to create an abstraction they
call 'session' it is hard to find one that handles membership in a
usable and flexable fasion (rumor has it WebObjects has a rather nice
model in this regard, of course you have to drop some TALL cash to get
it).  We want our system to be able to satisfy most requirements, and
be able to be molded without breaking any of it to fit all the rest.
For example, membership should be flexible enough to store membership
information in an SQL database, but it should not be required.

So, that aside, I can tell you that this is a deep problem we are
thinking about actively here at DC in various top secret projects, and
we plan on solving in the usual ultra cool Zope Zen way.


> 
> (At first sight the feature now called "versions" seemed to do something similar
> but this was only the first sight.)
> 
> A Session (in my definition) should provide a private namespace for exactly one user
> (or web client). It should have an optional timeout in order to destroy it if the 
> user is inactive.
> 

Ah there lies the rub.  'exactly one user' is not a concept currently
in Zope.  It is possible for me to create users called 'michel' at
various and disjoined areas of Zope.  This is a wildly usable feature
of Zope.  Creating 'members' is a higher level concept than this,
members should be singular, there should be no two 'Michel' members in
the same 'membership'.  Members should have an area that is 'theirs'
(like the UNIX concept of a home directory).  etc. etc.  It gets
sticky and easy to paint oneself in a corner.

> Has anyone build a nice Zope product which does this?
> 

I believe there is a product somewhere out there that lets you
manipulate cookies in the browser to store some small amount of state
(something like 4K) on the client.  I believe it was called
CookieCutter.  This could be useful for your short term goals.
Perhaps the author could chime in?


> May be sessions could be integrated into the object database 
> (by declaring objects to have a special scope and extent)?

We generally avoid putting HTTP specific (or even Zope specific)
feature in the database, this grossly violates our componentized
model.  The ZODB should (and is) be useful for a variety of
applications completely unrelated to Zope or the web.  In either case, 
the database is pretty transparent and low level at Zope's python API
layer, so the problem could be easily solved without bringing any
thought about the database into it.

-Michel

> 
> 
> 
> Frank 
> 
> _______________________________________________
> Zope maillist  -  Zope@zope.org
> http://www.zope.org/mailman/listinfo/zope
> 
> (For developer-specific issues, use the companion list,
> zope-dev@zope.org - http://www.zope.org/mailman/listinfo/zope-dev )