a new version of maildir

I'd like to propose some changes to the maildir format, for the sake
of making it easier to write MUA-type programs that may run
concurrently on the same maildir (e.g., IMAP server instances serving
multiple clients).  The central idea here is that changing one piece
of information (e.g., a message's "replied" flag) should not make it
harder for another concurrent process to find a different piece of
information (e.g., the message contents).

- Messages would not be moved from new/ to cur/; this newness
  information can be stored as a flag.
- Flags would not be stored in the message's filename.

For flag storage, I developed a different scheme for the maildir
backend in Gnus.  As with standard maildirs, each message is
identified by the unique part of its filename "uniq"; in the case of
files in new/, this should be the whole filename.  But each flag is
represented by a directory somewhere within the maildir - say,
"flags/replied/".  Messsage "uniq" has the flag "replied" iff the file
"flags/replied/uniq" exists.

Bonus #1: it's easier for implementations to add new, nonstandard
flags without bumping into each other - program foo can store flags of
its own invention in ".foo/flags/someflag/", etc.  Then, if a standard
flag is later introduced with the same semantics, users can keep their
old flags just by making a symlink for the directory.

Bonus #2: by symlinking directories, users sharing access to the same
maildir can share flags, or not, on a per-flag basis.  You and I can
see the same messages, and the same "replied" flags, but different
"seen" flags, if that happens to be useful in our situation.

To save inodes, each flag directory can contain a file ":", which we
make hard links to when setting flags.  But to support more than
NLINK_MAX messages, we must replace ":" with a new file and try
linking again if the first attempt yields EMLINK.


paul