nmh-workers
[Top] [All Lists]

Re: [Nmh-workers] Braindump: Extended MH Format

2004-12-10 00:42:43
Chad Walstrom wrote:
I posted this as my ~/.plan file on my website... my crappy
web-log-ish-thing.  I highly doubt anything I have to say is new, but it
helped me form my opinion about Maildir, that it's not really worth the
attention it's getting.

While I'm not necessarily a fan of maildir, it does have some nice
locking semantics (and locking that works over NFS is a Hard Problem).

   If the only compelling reason to switch to Maildir from MH is the
   file locking semantics, why not fix MH? Rather than storing index
   data as the file names themselves, why not leave it up to the email
   client or IMAP server to store sequences in meta-data files? Perhaps
   as an additional field in .mh_context or a separate file.

If you're going to change format, it might be nice to have something
with a separate overview index. I played around with adding threading
support to nmh a while ago but the trouble is that you wind up having
to read all the messages concerned to build up the thread tree before
you can start doing things, so "scan -threaded last:100" feels far
too slow... (GNUS already has a format like this, which it calls nnml,
which is nmh with a .overview file containing some headers from each
message. I haven't actually looked at the implementation, though.)

Any merit to this idea?  I understand it would change the way sequences
would need to be handled, but we could hide that in a library call.  The
command-line utilities don't need to change the way they reference an
email.

It makes it harder to do things like 'grep foo ~/Mail/inbox/3???', of
course... And since you need to lock the .mh_context to change virtually
anything in the folder you might as well just say "don't change anything in
the directory unless you have a lock on the .mh_context file". Unless you
can come up with a scheme like Maildir that lets you go the whole hog and do
things without holding an explicit lock, I don't see the point.

As a nitpick:
Renaming a file is simply creating a new link and then removing
the original link

maildir works precisely because renaming is *not* creating a new link
and removing the old one -- it has to be an atomic operation...

-- PMM


_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

<Prev in Thread] Current Thread [Next in Thread>