Re: [Evolution-hackers] Introduction and Questions

[Jeffrey Stedfast <fejj novell com>]

On Fri, 2007-06-08 at 15:13 -0700, Ross Boylan wrote:
> On Fri, 2007-06-08 at 17:11 -0400, Jeffrey Stedfast wrote:
> > On Fri, 2007-06-08 at 12:23 -0700, Ross Boylan wrote:
> > > On Thu, 2007-06-07 at 09:25 -0400, Jeffrey Stedfast wrote:
> > > > it's not possible to do better w/o dropping features like message
> > > > threading.
> > > > 
> > > > In fact, the above minimalizing of header fetching already breaks the
> > > > quick context-menu "vfolder on mailing-list" and "filter on
> > > > mailing-list" features as well as making vfoldering on mailing-list
> > > > oodles slower (if it even still works after disabling the headers) 
> > > What about letting the server do the threading, if it can?
> > 
> > 1. not all servers support it, so we need to implement threading
> > client-side anyway
> > 
> > 2. not all servers do it /correctly/, so we'd need to have a lookup
> > table of server idents so we knew when to fallback (note that every mail
> > client I know of that tried to be smart and let the server do the
> > threading has lived to regret making this decision)
> The parenthetical remark is pretty interesting.

(Balsa is one such client, if you are interested)

> > 
> > 3. if threading behavior is different from other accounts, it will feel
> > "weird" to the user.
> All good points.  I should explain I'm thinking of a mode that might
> kick in only on "large" mailboxes, or as a user option or something like
> that.  My main concern is that with very large folders most mail cients,
> including evolution, become sluggish to the point of being unusable.
> For many of the clients life is much uglier during the initial contact
> with the folders than later.  For example, when I move a message into a
> folder I haven't opened or operated on in evolution, I'm noticing long
> delays (like > 1 minute) while it does something (fetch headers and
> create an index?  whatever it is uses some, but not all the CPU).

yea, it's creating a summary.

IMHO, the design needs to change such that a CamelFolder object need not
load the summary when instantiated. If that gets implemented, then
there's no need to hit the server to sync summary info before the object
gets returned to the caller who requested it, thus allowing appends w/o
this particular slowness.

This is all part of my camel architecture redesign ideas that I had
started implementing in libspruce as a testbed. I think Michael Zucchi
even started to implement this in the disk-summary branch (it basically
boiled down to ::open() and ::close() methods on a CamelFolder object)

> 
> In this context an responsive but imperfect solution is better than an
> unresponsive perfect one.

I would argue that it's not a perfect solution if it's unresponsive :)

> 
> For example, if evo relies on the server's threads then it will
> obviously inherit their behavior, warts and all.  In general I agree
> with the point, made recently on this list, that it's desirable for
> clients to shield users from server problems (and most users don't know
> and don't care that the the "real" problem is with the server).  But if
> doing so takes forever, some may be willing to give up on that.
> 
> Whether relaying on server side threading, which currently only operates
> on the whole mailbox, can solve the performance problems is another
> issue.

it doesn't operate on the whole mailbox, it operates on a seqid or uid
set afaik.

been a while since I've read the specs