performance issue (imap spool on san)

[Nikola Milutinovic]

> > The first time you open a large IMAP folder is not very fast, I have to
> > admit, but I didn't find any other comparable IMAP client without this
> > problem. Perhaps there are some, but I didn't try them because of the
> > lack of other basic email features.

> This is why they aren't IMAP clients.  IMAP servers make all manner of 
> searching, sorting, retrieval, and storage options completely available to 
> the client, without having to download even all the headers.  This is why 
> Mulberry, Pine, Mutt, and Kmail are so much faster.  If TBird would just do 
> that instead of insisting on blindly attempting to download all the headers 
> and performing all sorting and searching on the client.  TBird and most of 
> the others have their roots and brains seated back in the POP3 dark ages 
> near as I can tell and that's how they treat all mail stores.  IMAP allows 
> the clients to easily ask for threaded views (unless you turn the index 
> options off or something like that) from the server, as well as partial 
> sets of headers in batch.  This massively speeds things up when you're on a 
> modem, or working with large mailboxes, or mailboxes you only occasionally 
> open.

I must say I'm a bit lost here. I have been using and administering Cyrus IMAP for years now, so I'm not really a new kid on the block.

Say you have a GUI IMAP client XxX. Say you start it up and click on the INBOX. What would you desire/expect XxX to do?

I would expect to see all mail headers in my inbox.

So, how do you do that in XxX, other then fetching all mail headers? How do you do that in Pine and Mutt?

Now, fetching it EVERY time, well, that would make me switch to another client. So, caching comes in. Of course, that introduces the issue of synchronization, not just for new mails, but also for mails deleted outside that client. I'm not sure how TB handles that.

What is your "modus operandi" in Mutt or Pine for this? If I understand correctly, you just make IMAP queries to the server and display what you desire. Hmm, call me lazy, but I would mark such a feature in TB unwelcome. When I click on the INBOX, I expect to see it's contents. That is the semantics I'm used to, when I "click on a folder". Is this semantic somehow confronted to the root philosophy of IMAP client/server?

Furthermore, if TB is implementing those semantics in IMAP protocol in an undesirable fashion, what should it do to become desirable again?

And don't get me wrong, there were a couple of features in TB that made me reach into my "dictionary of less than favourable epitets". Like connection caching, which made my installation crash (it could have been my mistake in not applying some patches). For that matter, OE has a similar feature, which when turned on, made my IMAPD processes die (something like "include this folder/account in sync on startup" or something like that). That looked like a bug in the server, but never mind. I didn't quite understand the need for connection caching on a single IMAP account. It just opened up to 5 connections for each folder I opened. Well, at least it can be turned off.

Nix.