Jon Fairbairn <jon(_dot_)fairbairn(_at_)cl(_dot_)cam(_dot_)ac(_dot_)uk> writes:
Paul Vixie <vixie(_at_)isc(_dot_)org> 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 <wohler(_at_)newt(_dot_)com> aka
<Bill(_dot_)Wohler(_at_)nasa(_dot_)gov>
http://www.newt.com/wohler/
GnuPG ID:610BD9AD
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers