[Web-SIG] Web Container Interface

[Ian Bicking]

Phillip J. Eby wrote:
>>   For instance, how do I implement sessions?  I don't see a portable 
>> way to do that in the service given this interface.  I don't even see 
>> an unportable way to do it.
> 
> If you were writing a plain CGI, how would you implement sessions?  
> That's precisely how you'd do it here.  And any existing framework that 
> does sessions for HTTP is mappable to this.  For example, my 6-years-old 
> ZPublisher app that's cranking out 4 million dynamic pages or so per 
> month under this interface, uses cookies.  It uses a Zope HTTPResponse 
> object, calling 'setCookie()', and it reads the cookie from an 
> HTTPRequest object.

Well, let's use sessions as an example, since it's really the example 
that gives me the most concern.

If we have a goal to move existing frameworks into a application/service 
model, connecting to multiple gateways, we have to support the behavior 
that already exists in those frameworks.  Cookies alone aren't sufficient.

Currently Webware's primary session mechanism keeps the session in 
memory until the session reaches a certain age (likely because the user 
has gone away), at which time the session is pickled and moved to disk, 
in case the user comes back.  This is done with a scheduling service 
that is part of Webware, as is the ultimate expiration (where the file 
is removed).  Locking is handled with thread locks, because Webware 
expects a single-process model.  Also, when the AppServer is shut down 
or restarted (which can happen very often during development), all 
sessions are pickled and written to disk.

So, there's an existing session mechanism.  The exact details of the 
implementation don't have to be maintained, but the external interface 
and semantics should be.  That involves:

* Sessions that persist over multiple requests.
* Sessions persist over server restarts.
* Objects put into the session do not need to be stored in client-side 
cookies.
* Some concurrency protection (applications still need to consider their 
own concurrency requirements).
* Sessions are expired in a consistent, scheduled manner.

Now, most of these can be implemented for CGI.  The last one would 
probably be slightly different, in that there may or may not be a 
scheduling service -- cron job or otherwise -- so an ad hoc scheduler 
that runs whenever a session is fetched may be necessary.  But the 
*implementation* would be significantly different depending on the 
context.  Webware's currently implementation wouldn't work in CGI, and 
to determine an optimal implementation it has to know something about 
the environment it's being run in.

And, to make it a little harder, we've often had requests to implement 
memory-only sessions, to put unpickleable objects into the session. 
Usually we just tell people to keep these values in module globals.  But 
module globals are also unportable across environments.  Probably the 
most compelling example of putting a unpickleable object into a session 
is to use database transactions that span multiple requests.  Of course, 
outside of a threaded server this just isn't possible at all.  (Well, 
maybe some clever use of a Pyro threaded server that serves up only 
database connections...)

Something that isn't an issue is getting the session ID from different 
locations -- a cookie, a URL variable, or a portion of the URL path. 
The application can handle this on its own -- but that's only a small 
part of the picture.

Pooling and caching systems also have to deal with many of the same issues.

   Ian