On 12/7/2011 3:39 AM, Ken Hornstein wrote:
I was thinking that if we want to have something that IMAP already uses
to refer to messages that is close to how message numbers work today
in exmh, then that would be useful. But you say below that you want
something more permament than how message numbers work today in IMAP.
sadly, what i want doesn't matter. it's not a pony, by the way, i have several
of those. what i want is for mark crispin to define IMAP in terms of how MH
worked at that time. lacking as i do a time machine, what i note as ineffable
current facts of reality are as follows:
1. IMAP UID's are permanent. neither a IMAP UID nor the header of a message can
change once that message has been entered into a folder. so, "anno" is
structurally incompatible with IMAP. and MH message numbers, due to "sortm" and
"pack", are incompatibly dissimilar to IMAP UID's.
2. IMAP message numbers are ephemeral, they change every time a message is
deleted from the folder. IMAP message numbers are also therefore incompatibly
dissimilar to MH message numbers.
3. MH would need to create its own mapping of message number to message file,
generating it upon need, regenerating it upon need, or keeping it up to date
Now, as for how Dovecot converts that to a IMAP UID ... does there happen
to be a file called "dovecot-uidlist" somewhere? From what I see that's
how the mapping from IMAP UID to filename happens.
[ss:amd64] head Maildir/.w.isc/dovecot-uidlist
3 V1307807266 N1 G39749f2dc60a544e417d0100ed0edd69
[ss:amd64] ls -l Maildir/.w.isc/dovecot*
-rw-rw-r-- 1 vixie staff 30 Dec 4 18:54
-rw-rw-r-- 1 vixie staff 63722 Dec 7 15:13
-rw-rw-r-- 1 vixie staff 27608 Dec 5 18:49 Maildir/.w.isc/dovecot.index
-rw-rw-r-- 1 vixie staff 912384 Dec 7 17:26
-rw-rw-r-- 1 vixie staff 5676 Dec 7 15:13
-rw-rw-r-- 1 vixie staff 32828 Dec 5 18:45
however, MH need not depend on any of this. we'll just make our own
mh.index or whatever.
I see that Dovecot seems to use a simple text file; maybe that's good
enough for a first-level effort? Or perhaps because it's longer running
it's not as much of a performance drag.
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.
Nmh-workers mailing list