Re: [Evolution-hackers] Introduction and Questions

[Ross Boylan <ross biostat ucsf edu>]

On Fri, 2007-06-08 at 18:27 -0400, Jeffrey Stedfast wrote:
> 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:
.....
> > 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)
> 
Why does it need to create a CamelFolder for the destination at all,
assuming I keep the focus on the source folder?

Actually, I guess I don't know if IMAP copy/delete is happening behind
the scenes, or if camel is creating the message from scratch in the
target folder.  The latter is a lot more work (though probably easier to
implement).

Second question: even if it creates a folder, does it need to stick
around for the folder creation to finish?  I think I remember seeing
that camel was single-threaded, relying on the client app to do
threading.  Would there be a way to multi-thread this somewhere (either
in camel or in the app)?  Obviously doing so would complicate things,
because at some point one might need to block (e.g., if I move a message
from folder A to B and then switch the UI to look at B).

> > 
> > 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 sure.
> 
> > 
> > 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
> 
I was mistaken about threading being only for the whole box.  I just
looked at
http://www.ietf.org/internet-drafts/draft-ietf-imapext-sort-18.txt and
see you can add additional search specifications to limit your thread
request.  Of course, clients might still ask for all the threads.

Though I've mostly focused on responsiveness, the "index the whole
folder" strategy also impacts bandwidth (as Philip pointed out) and
local disk useage.

Ross