performance issue (imap spool on san)

[Daniel Eckl]

Hi Nikola!

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

Well, you cannot see _all_ of your headers when you have a big mailbox 
full of mails. You can only see a few of them, perhaps 20, or 50 or so.

The client theoretically would be able to clarify, how many emails it 
can show to the user, depending on the height of the message list 
window. Then it could just fetch only the headers of the messages, which 
it can show you now.

As soon as a user scrolls, it can fetch the next few headers.

My opinion: That's fine in an Webmail Client or in a console based 
client, where you only can scroll line by line or page by page.
I don't know what a graphical client should do, when a user drags the 
view with the vertical window slider and scrolls up to down to up in 
between 3 seconds.
The client would have to try to get all headers in 3 seconds? Or should 
he just show n/a to the user until he stops? Very bad idea in my eyes.
I often scroll through my whole mailbox searching for a specific date 
range or similar. I don't want to issue a search query because of that 
task, that would be very non-economical.

So in my opinion: you cannot use this behavior in a graphical client. 
Well, I have to believe that mulberry can do that somehow, I cannot 
check that, this program and its vendor are non-existant anymore.

But I know: The smaller your bandwith to the server is, the nastier 
would be the delay you have when you scroll through your folder 
searching for something.

Best,
Daniel

Nikola Milutinovic schrieb:
>>> 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.
> 
> 
> 
> ---- Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ:
> http://cyruswiki.andrew.cmu.edu List Archives/Info:
> http://asg.web.cmu.edu/cyrus/mailing-list.html