Re: Maildir header cache now supports imap, too

[Thomas Glanzmann <sithglan@xxxxxxxxxxxxxxxxxxxx>]

Hello Tamo and others,

* TAKAHASHI Tamotsu <ttakah@xxxxxxxxxxxxxxxxx> [040807 12:53]:
> Then, please understand the difference between locking "DB files"
> and locking "mailboxes."
> If a mailbox is locked, the mailbox doesn't receive new mail.
> If a DB file is locked, mutt falls back to RO or no-cache mode.
> Mailbox-lock is fatal, but DB-lock is not a problem at all.
> (This is Thomas(Gl)'s point, if I understand him correctly.)

you do.

> Even if mutt causes a dead-lock, we can simply delete the DB file
> or "set header_cache=anotherfile."

True. But at the moment there can be no such 'deadlock'. That's because
gdbm know how to handle locking correctly in a way that dumb developers,
like me, understand it. :-)

And for the berkeley db ... we have no locking at all *at the moment*.
And I tested the berkeley db stuff thanks to William R Sowerbutts very
intensive. However with the current implementation which was submitted
by Brian Feldman it's possible to get header cache into an unstable
state which causes mutt to crash (but you have to try hard). However I
am reading berkeley db docs at the moment and will soon come up with a
safer implementation. So please don't use the berkeley db stuff with
header cache at the moment. And as I always said. gdbm is safe and
faster anyway. :-)

> And, DB files should be on local machines not only for the locking
> problem, but also for speed matter, which is only one reason we use
> header-cache. IMO, header cache files on NFS don't make sense.

In some cases it makes sense. But not on the 0x815 setup. For example we
have a CS pool at FAU with NFS shared homes and 130 Linux client. If you
want to read your eMails using mutt on different clients all the time, a
NFS header cache would make sense.

However all people I know have mutt run on exactly one machine in a
screen. And I know about 10 people who do it that way. All of them of
course are forced to use the header cache. :-)

        Thomas