performance issue (imap spool on san)

[Daniel Eckl]

Hi David!

All your points are fully correct. But changes nothing to my basic
saying: It's plain wrong to say thunderbird is NOT an IMAP client.

It might be a very bad IMAP client regarding this one feature, but it IS
an IMAP client. It's fully RFC compliant, it does not matter if it uses
all IMAP features or not.

And for nearly all users, only graphical clients are usable at all.

So for nearly all users, Thunderbird is the best availiable IMAP client.
Only some very few console based IMAP clients are better in at least one
feature: Fetching headers on demand.

I just want to have this stated.

To be provocative and exaggerating just isn't netiquette and if the said
statement is plain wrong, it's really bad and has to be corrected.

Even lynx is a web browser, although it cannot do some very basic things
 everyone expects a web browser to be capable of.

So I hope everyone can agree with my statement and this subject can be
closed now.

Best,
Daniel

David Lang schrieb:
> On Wed, 26 Jul 2006, Daniel Eckl wrote:
> 
>> Hi Michael!
>>
>>> Thunderbird is NOT an IMAP client.
>>
>> I don't want to start a flamewar, so I tell you that I write this email
>> with a very polite temper in mind. Just to not set you up. But you have
>> to admit, your saying is extremely provocative.
>>
>> Please can you explain your saying? Pine and Mutt both are console only
>> applications and I think you simply cannot compare them to a graphical
>> client like Thunderbird.
>> An unix-unexperienced user will even simply fail to use them at all,
>> because the text interface is so limited by console possibilities, that
>> it cannot be intuitive in any way.
>>
>> In a graphical client you want to be able to scroll through your whole
>> message list without any delay. So I think there is no other chance but
>> caching all header information of a folder. On low bandwith situations
>> it seems to be impossible for me to do this on demand only.
> 
> it has nothing to do with being graphical or not.
> 
> the key is how it manages the mail.
> 
> a 'true' imap client realizes that the server holds all the info and it
> can query individual pieces as needed (headers, flags, including
> sorting, searching, threading, etc)
> 
> a pop3 client that knows some IMAP uses the IMAP commands to fetch the
> data, but it stores it locally, just like it stores pop3 messages, and
> all actions (including searching, threading, etc) take place against the
> local copy of the messages.
> 
> since pop3 is such a simple protocol many mail clients start with
> support for it and then add "IMAP support" by substatuting IMAP commands
> for the POP3 commands, but otherwise operates exactly the same. This is
> what Thunderbird does.
> 
> unfortunantly there isn't a true IMAP client that's graphical available
> to my knowledge (which is why I still use pine)
> 
>> I was searching for a full featured graphical IMAP client for a long
>> time and tried everything and I have to say: Not only is thunderbird an
>> IMAP client, it is the best graphical IMAP client I could find in the
>> whole Linux and Windows world. It has the most complete feature set and
>> the most intuitive interface for both Linux and Windows users. And it is
>> way faster than every IMAP client with a comparable feature set. Kmail
>> is extremely near to my wishes, it only lacks IMAP IDLE support.
> 
> there are a lot of IMAP features that it doesn't use, not just IDLE.
> 
>> 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.
> 
> with pine it takes the same time for me to open a folder with 10
> messages in it as one with 10,000 messages in it, becouse it doesn't
> care how many messages are there and only fetches what it needs to, when
> it needs to. it does take longer to sort or thread a large mailbox, but
> that's server-side processing, which can be greatly assisted by caches,
> etc on the server (depending on your IMAP server software)
> 
>> Anyway: I'd happily listen to other suggestions for full featured
>> graphical IMAP clients which could be better than thunderbird. There
>> surely are things in thunderbird which could be a lot better! I just
>> need an alternative which I was not able to find yet.
> 
> nobody is saying that there's an available graphical IMAP client that's
> better then thunderbird, they are saying that there isn't a real
> graphical IMAP client period. all of them that are available, including
> thunderbird, are not makeing proper use of IMAP, and as a result they
> all suffer the same performance problems when you open a folder with
> lots of new messages.
> 
>> So regarding the performance problem of the original poster:
>> When I'm on my LAN, I can initially open a folder with 6000 mails in it
>> in about 30 seconds. I have a network throughput of about 900 KB/s. So
>> network just isn't the bottleneck. (see below)
>> After Thunderbird has this initial header download done, the folder
>> opens without any delay. It just downloads headers of new emails, so if
>> you don't get thousands of mails between two folder checks, there is no
>> problem at all.
> 
> and with pine I can open a folder with 21000 messages in it in less then
> one second, in spite of never having seen it before.
> 
>> It's very good that you can prevent the problem with kmail. This shows
>> that Thunderbird really has problems here, but you have to think of
>> normal users. On the user's side there is a lot of Outlook, Outlook
>> Express and Thunderbird which all will trigger the problem.
>> I think it will be better to eliminate this problem instead of working
>> around. You might find yourself in a situation where the server is in
>> high usage by your users and it's very hard to replace and migrate
>> mailboxes without long downtimes.
> 
> Outlook and Outlook Express have very poor IMAP support, Thunderbird is
> slightly better, but still poor when compared to other (unfortunantly,
> not graphical) clients.
> 
> David Lang