Re: [Evolution-hackers] Camel plans and possibilities

[Not Zed <notzed ximian com>]

On Mon, 2003-06-30 at 05:22, David Woodhouse wrote:
> On Thu, 2003-06-26 at 04:54, Not Zed wrote:
> > I put this (long) list together of a bunch of things that should be
> > addressed in camel.
> 
> Please could you also add (de-)prioritisation of background tasks to the
> TODO list for the IMAP back end. We don't want it checking for new mail
> for two minutes _before_ of fetching the mail the user just clicked on
> -- that's insane :)

This could be tricky, might need some rearrangement of locking, or
moving some processing out of camel.  That just covers splitting the
tasks up into smaller chunks that can be interleaved to improve
interactive performance.  Acutal prioritisation of jobs is another issue
:-/

> Likewise we need to fix the way it downloads a multi-megabyte attachment
> just to run 'file' on it, before even displaying the text of the main
> message part to the user.

Hmm, it shouldn't be doing that, it should only ever do the file thing 
on parts that are already downloaded.  Unless for example its marked as
an inline part which we have to download anyway.  Still, the text part
should be displayed first if the message is appropriately structured. 
I'm working on a total refactor of that stuff at the moment anyway and
the current behaviour might not be an accurate guide to where its
headed.

Both of these things would benefit from using imap more incrementally,
like downloading parts in smaller chunks using BODY[*]<x,n> calls, and
having a job queue and pipelining, etc.  Which is a bit tricky to do
with the current code, and probably a bit tricky to do with camel's
locking model too (i'm thinking much of the locking should be moved
primarily to the implementations) ... sigh.

 Z