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

[Ken Hornstein]

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