Re: [Nmh-workers] nmh on Maildir.

[Ken Hornstein]

>> So it would be helpful if we supported Maildir as a mailbox format,
>> because then we could use nmh directly on the backend store without
>> going through IMAP
>
>Could an optional level of indirection help;  mail/inbox/42 having
>content that states it's not the email, but here's details that allow
>the email to be found in a Maildir, including a fast method, and a
>slower one for if things have got out of sync.
>
>It would mean nmh commands that don't peek inside 42 don't care, e.g.
>`folder -pack'.

I think that the negatives there outweight the benefits.

First, the number of nmh commands that don't actually need to peek
inside of the message contents are very few I believe.  Secondly, I
share Paul's concerns about the number of inodes being used.  More
specifically, I think experience has shown us that doing readdir() is
expensive when the directory grows large; I believe opening and reading
a single file which maintains the the mapping from MH message number to
Maildir filename would be a lot quicker.  I'm open to being persuaded
otherwise.

In the larger view, for non-MH mailstore directories I was thinking
of a cache file that vaguely has the form:

#
# The is a mapping of MH message numbers to Maildir filenames
#
1 something-unique-1.something-unique-2:info
2 something-unique-3.something-unique-4:info

You get the idea.  One for IMAP would look like:

#
# This is a mapping of MH message numbes to IMAP message UIDs
#
1 88
2 200
3 997

And so on.

--Ken