Hi, I'm very fond of maildirs, they are simple, I like that. But I've never really understood the significance of maildir/new/. The only use I can see is that (for example in the case of dovecot), you'd move a message from new to cur and then update the index-file, that's it. So to make put it more direct, you'd know when and with what to update the index-file, based on where the file resides. I've never been bothered by them, until I found that that is the last hurdle for fast access to a large (and receiving a lot of mail) Maildir. I've been thinking long and hard about what to do to make them work even better. My idea at this point is the following, use maildir/new as little as possible, just use it for what it was intented and spread the time of updates. If someone would make a wrapper-program around the delivery-program (like qmail-local, vpopmaildeliver, procmail or local and virtual from postfix) and the delivery program would print to standard output the path+filename it saved a (or more) message(s) to, the wrapper would be able to send an update-message to a dovecot-daemon. That mean, updates are small, and opening a large maildir would be sped up. How does that sound ? I hope this is a helpfull suggestion. _____________________________________ New things are always on the horizon.
Leen Besselink wrote:>That mean, updates are small, and opening a large maildir would be sped up. > >How does that sound ? > >What difference does this make to simply telling dovecot to open the maildir periodically? You could do that easily in python: import imaplib conn = imaplib.IMAP4_open("/usr/sbin/dovecot --exec-mail imap") conn.select("targetfolder") conn.logout() Obviously you'd have python start overhead, but you can just use expect instead, which probably starts faster. Make your wrapper store a list of changed folders somewhere, and iterate over that list every couple of minutes using above script. Or am I misunderstanding something? Oh, the best would obviously be using the (planned to be upcoming, I believe) dovecot LDA (local delivery agent). johannes
Leen Besselink wrote:> If someone would make a wrapper-program around the delivery-program (like qmail-local, > vpopmaildeliver, procmail or local and virtual from postfix) and the delivery program would > print to standard output the path+filename it saved a (or more) message(s) to, the wrapper > would be able to send an update-message to a dovecot-daemon.I don't understand how this would be an improvement. Currently, when dovecot opens a "folder" the first thing it does is open folder/new and moves those files to folder/cur, presumably updating the index as it goes. That is as fast as it could ever get. Perhaps a short description of how Maildirs work (as I understand it) is in order: 1) an external application creates a files in ./tmp (this is the one time-consuming operation and it is not guaranteed to be atomic); 2) the same application then renames that file into the ./new folder (this is atomic); 3) another application (say dovecot) opens the Maildir for reading and moves any files from ./new to ./cur (since this neatly corresponds to "new" files as opposed to previously seen files). How would some additional information to the dovecot-daemon help in any way? The files in ./new are guaranteed to be, well, NEW, so they are the ones that dovecot needs to add to its own index, to avoid having to open the ./cur folder and enumerate all files every single time. John -- John Peacock Director of Information Research and Technology Rowman & Littlefield Publishing Group 4501 Forbes Boulevard Suite H Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5748