Re: Why isn't it part of mutt "proper"
* Thomas Glanzmann <sithglan@xxxxxxxxxxxxxxxxxxxx> [2004-08-18 17:01]:
[snip]
TG> Thomas Roesslers point was:
TG>
TG> Don't add locking mechanisms to Maildir, it was designed to work
TG> without locking mechanisms via NFS.
TG>
TG> My answer was:
TG>
TG> I don't add locking mechanisms to Maildir, but to the database
TG> where the cached header information are stored in order to
TG> prevent corruption due to multiple writers.
TG>
TG> bottom line: Maildir stays NFS safe *without locking* it.
TG>
TG> I also mentioned that the locking mechanims for the header cache
TG> database are NFS safe and *nonblocking*. Read: It tries to open
TG> the cache rw, if that fails ro, if that fails not. *Without* any
TG> blocking.
I understood why ME's implementation did not make it into the
tree (ME said himself it had some wrinkles, though despite my
extensive everyday use I never experienced a problem). This
implementation feels sound to me, I have also tested it quite a
lot and found it problemfree.
I get about 300 messages a day, they are filtered into various
mailboxes and caching headers speeds opening them vastly, making
reading mail enormously more confortable and faster. Which is
what having a good mail client is about.
Based on the above (NFS safety) and my quite typical (and thus
common) usage of MUA by user with relatively voluminous email
correspondence I would ask TLR to reconsider including hcache
into mail tree. It drives mutt's usability score from astronomic
heights even higher.
Thanks,
jz