"Christopher G. Petrilli" wrote:
How about from a single long-running process on a well known URL? Sessions could then be scaled beyond a single server.
This was my point with the concept of a SessionServer, which would be something seperate from Zope's main database. It would reside on a central server, and allow for multiple servers to resolve IDs into "Session" objects. These objects could even maintain state for some period of time after their last access (i.e. someone could be shopping, leave and come back in some manner)... you could also retreive them based on some other information, perhaps... a userid, or something.
I was thinking more initially about just a ticket dispenser, than a session manager. It's purpose would be to assure a unique id is passed to each requestor, possibly storing some information passed to it during the request phase. Session management would be a separate process.
Honestly, though, I'm not sure HTTP is the best protocol for this, but what do I know... I'd use XML-RPC over HTTP if I did that, otherwise I'd use something else like CORBA.
The main problem is getting all this stuff to work through proxies, I'm sure you're aware. I actually did manage to get Iona's Orbix to work through a firewall (thanks to hecurlean efforts on the part of Justin Mason @ Iona and a security guru at Sprint), but it's just not worth the effort. Nor does the current xml-rpc work through a proxy, at present (although it shouldn't be difficult to fix). HTTP/SSL pretty much works everywhere. Best regards, Jeff Bauer Rubicon, Inc.