Re: [Evolution-hackers] Introduction and Questions

[Jeffrey Stedfast <fejj novell com>]

On Fri, 2007-06-08 at 16:02 -0700, Ross Boylan wrote:
> 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?

because you need both a source and a destination folder to move the
message(s) to?

kinda hard to move messages to a folder if you don't know which folder
to move them to, don't you agree? :)

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

it uses imap COPY and mark-as-deleted

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

not true...

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

okay, I think you need to familiarize yourself with Camel's API before
we discuss anything further :)

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

when you think about it, it's really the only way to do it. The only way
to figure out which UIDs to display in the message-list 'window' in
threaded mode depends on being able to calculate which rows to show. To
do this, you need the whole thread model since you aren't able to
request a partial thread-model based on view row indexes (which would be
ideal)

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

disk usage isn't that much, it's something like 2% of the size of the
mailbox.

also, unless you want to repeatedly request the summary info from the
server each session, then you need to cache it. You also need to cache
it for disconnected operation.

Mobile-device users might not care to have this, but a desktop client
requires it.

That said, Camel is pluggable... someone could easily write a
mobile-imap provider that works the way tnymail needs it to work.

Jeff