-> So there are a couple of decisions to make.  First decision: who should
-> be responsible for session persistence, the session class or the session
-> manager class?  I strongly favour the session manager, because only it
-> knows about all sessions and thus it should manage the hash file, or
-> directory, or database connection, or whatever.  Anyone disagree?

Sounds good.

-> Here's the interface I'm leaning towards at the moment:

[ munch ]

-> How's that grab everyone?  Feels pretty right to me.  I think I'll code
-> it up and see how hard it is to implement a persistent SessionManager.

It doesn't conflict at all with how I'm using things, so as far as I'm
concerned it's good ;).

It sounds to me like the best way to integrate all of this into a
transaction-oriented database is to have the save_changes take an
in-memory representation and map them into the database, and then
do a commit immediately.  I'm using a home-grown object <--> database
mapping system that (like ZODB?) automagically transmits the changes
to the database, modulo a commit; does this change in session management
protocol mean that for this sort of database system, you'd either have
to decouple the session from the database-linked object until
save_changes() is called, or keep a separate transaction handle for each
session?

--titus