> On 29 October 2001, Quinn Dunkan said:
> > My "DB" is simply a directory of pickles, but the "application state"
> > is also the state of various system files (mailboxes).  It's important
> > that session be expired in a certain amount of time.
>
> If that directory of pickles is one pickle file per session, it sounds
> like you've got it easy.  Write a script to walk the directory, looking
> at each pickle (heck, you don't even have to load it: you could probably
> just look at the mtime), and deleting "old" ones (for some definition of
> old).  Run it periodically with cron, with a carefully chosen period.
> Eg. if you say "sessions older than 1 hour will be expired" and you run
> the script every 15 minutes, then a session could live to 1:14:59 before
> being expired.

Actually, the pickle-directory DB is for persistent data that lives forever.
When a user logs on, a session is created, and User.__init__ snarfs its
persistent state from disk.  Expiring a session means dumping the perisistent
data in User to the pickle (cheap) and syncing the User's cached idea of what
the mailboxes look like with the actual mailboxes on disk (expensive).  So
it's not really something that can be done with an external process.

> The problem with running every N hits, as Neil suggested, is that it
> could be quite a while before N hits elapse.  This is true even if N ==
> 1; as N decreases, the load on your server increases and the probability
> of sessions living on too long decreases.

Right, that's what I was thinking.

> Maybe you could keep a data structure in your session manager that
> classifies sessions by age, so you don't have to be a big expensive loop
> over all sessions every N hits.

Yeah, that was the sorted queue idea.  I'd still have to shuffle it around.
I'm happy to do my usual thing, which is to implement the simple, obvious
non-scalable solution and fix it if it actually becomes a problem.  Account
expiration is not something the whole app has its fingers in, so changing it
to something more complicated later won't be hard.

> > If someone forgets to log off, I'd like the system to log them off
> > after a well-defined period of time.
>
> I suspect someday Quixote's session management machinery should have
> some sort of support for this.  Right now, I don't think the right
> solution is obvious, so it's better to have a few different approaches
> implemented in the wild, and see what works.
>
> > If I didn't store the user name in the url (which is another possibly
> > unusual thing about my approach: the namespace looks like
> > Root_object.username.user_subobjects where Root_object uses _q_getname
> > to map usernames to logged in user objects) then the next person would
> > *accidentally* log into someone else's account.
>
> Hey, another thing just occurred to me: you could expire sessions "on
> demand".  Eg. user joe currently has a session open, and a request is

That's a good idea.  I could put that check in SessionManager.get_session().
It still doesn't help me very much, because I'd still like to expire the
session as soon as possible, because that's when I can unlock the mailbox.
I'd like to let the users see their mail again as soon as possible :)

> > Anyway, since I'm also forced to use the inefficient unix mailbox
> > format (have to get along with pine, you know) parsing a large mailbox
> > looking for message 500 and reorganizing messages is expensive.
>
> Have you considered Maildir?  AFAIK even Pine works with it.  I see lots
> of people on the Exim and ReiserFS mailing lists who are very happy with
> Maildir on ReiserFS for POP/IMAP servers.  Maildir would unload a lot of
> your job onto the filesystem, and ReiserFS is specifically designed to
> take that kind of load.  (A regular Unix filesystem would probably work
> just fine, unless you're talking tens of thousands of users with
> thousands of messages each.)  It also means you don't have to be afraid
> of writing changes to disk, because deleting a file is a hell of a lot
> cheaper than rewriting a whole mbox.  And you don't have to worry about
> the (potentially) long window between "user walks away from browser
> thinking their changes have been made" and "user's session expires and
> changes are written to disk".

Yeah, I looked at maildir.  It's definately the right solution (well, use IMAP
and forget about the web is actually the right solution), and all this ugly
hacking I have to do is because I'm solving the wrong problem.

Unfortunately, much as I'd like to lose sendmail for postfix or qmail or
something, I can't do that.  It's possibly possible that I could hook the
local delivery agent up to maildir or safecat and then convert all users to
maildir and patch pine (it apparently doesn't support it out of box, but there
are patches on qmail.org), but the amount of local hacking I can do and time
in which to do it is quite limited.  It's worth more research.