It seems that IMAP has the concept of a "message sequence number",
which is a number from 1 to the number of messages in a folder; that
might be the right thing to use.
no. MH message numbers can have holes and can be reassigned. IMAP is
always 1..N, no holes.
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.
Alright, moving on ...
Maildir/.Archives.2011/cur/1321741485.M572952P74802.ss.vix.com,S=1369,W=1407:2,FR
i'm not sure exactly what all that crap is or means, "1321741485" looks
like a seconds-since-1970, and "M572952P74802" looks a little like
device+inode. i don't know how Dovecot gets from that file name to an
IMAP UID and i don't know if it does so in a Dovecot specific way or
whether this is a Maildir thing (Dovecot-independent).
I can fill some of this in.
"Most of the crap" is something just guaranteed to be unique. Hence the
timestamp+device+inode+hostname stuff. S=1369 is the size of the file
in bytes (to avoid a stat()), W=1407 is the size of the file in CRLF format.
Those are Dovecot-specific extensions. Everything after the : are file flags
defined by Maildir (2 being the verison number, F means "user defined flag",
R means message has been read).
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.
the reason i'm thinking that we'll have a .dir/.pag file per folder is
to make sure that MH message number "X" remains more stable than an IMAP
message number would be, but less stable than an IMAP UID would be. we'd
generate this "db" the first time we visit a folder, we'd regenerate it
if the directory mtime was more recent than the "db" mtime, and we'd
update this db whenever we ran "inc", "refile", "pack", "rmm" or
"sortm", and we'd access this db whenever we ran "show" or "inc" or
"repl" or similar.
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.
--Ken
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers