Re: [Evolution] 1.1.1.99 Issues

[Not Zed <notzed ximian com>]

On Sat, 2002-09-21 at 03:32, Jeffrey Stedfast wrote:
> On Fri, 2002-09-20 at 10:30, John Graber wrote:
> > On Red Hat 7.2:
> >
> > 1)  I have my mail accounts set to leave messages on server.  On a
> > seemingly random basis, Evo is downloading multiple copies of messages.
>
> Is your POP servers one of those lame servers without UIDL support that
> also changes the message headers after downloading the full message? If
> so, this is probably why (take note of the Status: and/or X-Status:
> headers - they are probably not there with the first download but are
> for the second).
>
> I can't think of any other reason this could possibly happen.

The new code is supposed to ignore status and x-status though.  But
thats not to say there isn't moer headers?  (X-)keywords perhaps?

I can't remember what the old code did ...

But if you're using pop, and your server doesn't support uidl, you
really have to just turn off 'keep on server', or suffer the speed
problems.  But see below ...

> > 2)  The in speed for checking mail SIGNIFICANTLY decreased immediately
> > after going from 1.0.8 to the beta.  It looks like it is during the POP
> > summary retrieval.
>
> I don't believe you.

If we have to get the headers to generate message id's, it could be
slower.

What jeff means here is that for most users, pop is now 3-4x faster
(depending on network latency, higher latency, the faster it is now).
 
> > 3)  Expunging messages for folders with a few hundred messages in them
> > is taking noticably longer.
>
> For what? local folders? IMAP folders? What?
>
> I've had reports that it is noticably FASTER for IMAP (and it sure seems
> that way from where I'm sitting too).
>
> Local folders might be a tad slower? But if so, it's probably something
> to do with cleaning out the mbox.ibex files that everyone complained
> never shrank in the 1.0.x series. I gues it could also be related to
> also updatuing the Status: and X-Status: headers in the mbox files so
> other mail clients like Pine can understand the flags (but this is not
> turned on by default I don't think?)

For local folders, there should be no case where 1.1.x is slower than
1.0.8.  1.0.x was slow mostly *because* of ibex - the other code hasn't
really changed at all.  The status stuff isn't turned on by default yes,
its only for spool folders/trees.

It does sound like there could be something wrong somewhere, though i
dont really know what to ask you to try.  Almost everything about
downloading pop mail to a local folder should be a lot faster -
noticeably faster.  Expunging should be faster, etc.

I'm not sure if the debug logs would show much.  When expunging is the
disk incredibly busy?  The cpu?  After visiting folders for the first
time, which will be quite slow if the folders are large (various indices
need to be rebuilt because of version changes), do they speed up on the
next visit, etc.