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

[pmaydell]

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