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
--
Nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers