Hi, Michael :-).umm, yeah sure. I have nothing better to do - maybe more /. reading...
On Tue, 23 Sep 2003, Michael Amster wrote:
something like this for each folder (note I have 744 folders and this takes about 1s per folder - it also pins CPU at 100%):
001 LIST "" "INBOX/myfolder/%"
So you can't wait 12 minutes for each mail you recieve?
Luxury. ;-)
If we configure BincIMAP as drop is Maildir++, does that let us leverage the same things? Is there a cache of scanned folders that we can see if there is a timestamp change for new changes? Can we leverage the "modified" flag of the directories to only scan the new ones?
Mozilla does not do this and it performs fine with BincIMAP. I have heard that the Evolution people only test against CourierIMAP, so Andreas may want to optimize Binc to work with Evolution's crappy IMAP verbosity.
Every LIST request takes up an equal amount of resources (IO and CPU) today. Courier-IMAP has the advantage that it knows all mailboxes are of
Maildir++ type, and that it only needs to scan mailboxes that start with a
dot '.'.
I have one idea on how we could optimize consecutive LIST or LSUB commands, as the first request needs to be approximately the way it is today. We could add a cache to the list of mailboxes, and have it invalidated as soon as a non-LIST command is requested.
That would make the first access as slow as now (1 sec), while all
following requests would require no I/O and would therefore be very fast.
I believe that this would solve the Evolution problem and probably make other clients' multiple LIST requests faster too.
Andy :-)
Since I am more of Java person than a C++, I could look at the source, but you may not want me playing with it unless I get up to speed (I used to write C for 10 years before Java).
-- Andreas Aardal Hanssen | http://www.andreas.hanssen.name/gpg Author of Binc IMAP | "It is better not to do something http://www.bincimap.org/ | than to do it poorly."
