[KLUG Members] Re: Evoluion 1.2.1 -- hmmm, may be an site issue ...

[Adam Tauno Williams]

>>Thats what I did at home.  Originally I was using Sylpheed, which is
>>maildir.  But do to massive amount of mail it was *SO* slow, and the
>>beast would devour thousands of file handles and bloat to consume
>>enormous amounts of RAM.
>That's just a dumb app. 

Sure.  

Many open source clients don't index mailboxes except in RAM, which makes the
initial opening every time a real drag.  The arguement is that there is no
standard way to store mail box indexes - some people don't use evolution because
they think it has done an "embrace and extend" of mbox, since it does store
on-disk indexes.

>Even Outlook 2K doesn't show you each message in
>a large folder if you quickly scroll down the messages -- it just
>waits till you get there and then opens it. 
>Once it have them indexed, why leave the files open? 

It creates a persitant index (it doesn't use mbox or maildir).

>What if he or she has two clients working?

With maildir you should be fine, albiet it won't be any faster.  With mbox using
multiple clients is russian roulette with all six chambers loaded.

>When reactionaries complain that people use thread support to avoid
>event handling and resource management, that is what they're talking
>about.

Hm,  I don't follow.

>>I switched to local IMAP (UW), and back to mbox, and it solved my
>>problem.  
>??? Does UW-IMAP use mbox to store mail?

Yes, that is why it is dog slow with large mailboxes unless you have heaps of
RAM.  When I was using UW on my mail-server (which is sitting on a bench behind
me, don't ask why) the hard drives ground all day long like four chainsaws. 
After switching to Cyrus, which maintains on disk indexes of just about every
element of the header and a few other things - nothing but the occasional chirp.
 I have a set of users that move huge files around in e-mail all day long, so
the effect was probably exagerrated for us, but it makes the point.

>>Whether UW is just more intelligent, or dividing it over multiple
>>processes helped... whatever, it was a huge improvement in
>>responsiveness.
>You have to think, as a mail server and not an MUA, it *must* manage
>its resources or else.

Yes, and those guys at University of Washington are pretty smart; I mean, look
at "pine".... er.... no, never mind.

>>Cyrus IMAP is probably over kill for most home installs,  
>~5 MB on my hard drive, not including actual mail; the worst part of
>Cyrus was reading all the dire warnings in the docs.  

The docs are scary,  but it is pretty easy to setup out of RPMs and I assume
Debs.  But it would probably snow anyone who hasn't worked with mail servers in
the past.

>No, SASL was the screaming pain.

Yup.  I can's say the docs on SASL are that bad,  but only because I can't find any.