[Web-SIG] and now for something completely different!

[Robert Brewer]

Ian Bicking wrote:
> Shannon -jj Behrens wrote:
> > Heh, I'm overwhelmed by too much code and not enough direction. 
> > Naturally, I've got nice session code in Aquarium as well.  *Sigh*
> > this Python Web thing is going to be the death of me!
> 
> If everyone is reasonably comfortable with what sessions 
> should do, can we just design an API and figure out the
> implementation later?

That depends on where you draw the line between the two. ;) It's pretty
easy to define an "implementation-less" API that consists of: create,
read, update, delete.

The first critical implementation discussion (which affects the API)
should be around concurrency, and if multiple locking strategies need to
be supported. In flup, for example, the entire session store is locked
if the same session is requested more than once simultaneously.
Pythonweb doesn't seem to mention concurrency at all. Paste mentions
it's not supported. ;) Quixote's session2 stores have flags for
multithreading/multiprocess but seem to not actually do anything with
those flags.

The concern is not only response time, but atomicity. In the comments
for Aquarium's SessionContainer:

    "Concerning locking:  in general, a global lock (of some sort)
    should be used so that creating, deleting, reading, and writing
    sessions is serialized.  However, it is not necessary to have
    a lock for each session. If a user wishes to use two browser
    windows at the same time, the last writer wins."

That is a design decision which not all frameworks (or other consumers
of our session lib) might share. Apparently, given the current Python
session modules out there, it's common to survive without caring? I know
Mike Robinson has worked many long nights trying to make a session
module for CherryPy which can consistently pass simple hit-counter
tests. ;) Personally, I'd like to pursue an MROW solution.

It would be nice if our final product supported multiple concurrency
strategies. The decision about which strategy to use could be left to
framework authors (who would wish to begin migration by maintaining
maximum backward-compatibility), or to their users, if those options can
be described simply enough.


Robert Brewer
System Architect
Amor Ministries
fumanchu at amor.org