>> 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