Re: [Nmh-workers] nmh in near, medium, and far-term

[Bill Wohler]

Jon Fairbairn <address@hidden> writes:

> Paul Vixie <address@hidden> writes:
>
>> dovecot is mapping a thing that does not change (IMAP UID) to another
>> thing that does not change (message file name). therefore they never
>> have to edit or rewrite this file. if MH used a text file then we would
>> have to copy it to mumble.new with changes, and rename it back to
>> mumble, every time a message's message number changed. this seems like
>> it would be harder to implement, as well as slower, than a "berkeley db"
>> thing (.dir and .pag files). ymmv.
>
> I’ve never really liked the fact that mh messages files change
> their names. For one thing, it makes archiving mail folders
> relatively messy because (for a particular example) sortm
> scrambles the relationship between filenames and contents. On
> the other hand I really like the fact that mh stores messages in
> plain files, with directories for folders.

Not just archives, but indexes too and the anno program too. I use
mairix to index my mail, and occasionally it takes me to the wrong
message, or complains about a missing file.

Also, if you reply to a message that you later refile or pack before you
have sent your draft, anno will Do The Wrong Thing.

> Long ago, before mh I used an email system that stored email in
> files with unique ids, which suggests a way to do this. Switch
> to storing messages in (say) date-named accession order folders
> with unique filenames (derived from the message-id, or simply
> accession numbers) while the mh folders would contain symlinks
> to these with numeric names as now. So (to continue the example)
> sortm would not rename any message files, but just rearrange the
> symlinks.

Or hard links.

This is definitely worth looking into. I think I might avoid using a
checksum as the name as anno would mess that up. (Since in MH, the file
*is* the database, I think that updating the file with anno information
is more the MH way to do it than to support an external database.) It
also doesn't present any metadata about the message, unlike the IMAP
UID.

As in IMAP, I think it would be more important to avoid renaming the
file, so an anno update should not change the name. If the size is in
the name, it should just be a hint to the MUA about the order of
magnitude of the size of the message.

-- 
Bill Wohler <address@hidden> aka <address@hidden>
http://www.newt.com/wohler/
GnuPG ID:610BD9AD