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

[Peter Buxton]

On Tue, Dec 17, 2002 at 11:35:27AM -0500, Adam Williams wrote:

> Many open source clients don't index mailboxes except in RAM, which
> makes the initial opening every time a real drag.  

Mutt does that with mboxes; it speeded up the process no end when I
copy-looped them (the poor man's defrag :).

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

I would argue, if they wrote a nice, small doc on what an mbox index
should look like, and explicitly versioned these indices, that that is
the opposite of embrace and extend. This is exactly like picture
thumbnails -- everyone has their own preference, no one wants to work
out a deal.

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

But it creates or updates the index, whether it does this once per new
message or on every startup. Either way, why leave the files open?

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

Use a better client. I often open mutt again in a new window -- and did
it when I had mboxes. No, it's not brilliant, but mutt was always *very*
well-behaved with file locks and checking before writing. I'd come back
to the first window and see the complaint: "Folder has been altered."

True, a maildir-like folder greatly minimizes the chance of some obscure
race trashing your files, but most mail clients can edit mails directly,
so you're never completely protected from a bad client, so -- why not
use the best? ;-)

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

In the long march to make *nix highly threaded, some people (John
Ousterhaut of Tcl/Tk comes to mind) thought threading was, ah,
"intellectually unsound," and inferior (not wrong, just inferior) to
structuring by event handling:

http://home.pacbell.net/ouster/threads.ppt

My point is that Sylpheed doesn't do proper event handling (when to
open/close/reindex the files) or resource management (too many file
handles). I was just saying it sounds like a bad example, in a kind of
odd, idiosyncratic way.

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

:-)

-- 
for gpg key: http://killdevil.org/~peter
So you had better do as you are told
You better listen to the radio. -- E.Costello, 1977