Re: [Evolution-hackers] Introduction and Questions

[Philip Van Hoof <spam pvanhoof be>]

On Fri, 2007-06-08 at 20:45 -0400, Jeffrey Stedfast wrote:
> On Fri, 2007-06-08 at 18:34 +0300, Philip Van Hoof wrote:
> > The imap4 project is making things look better, though all in all it's
> > still much of the same (blocking and waiting for results, in stead of
> > letting the server do most the work and do pipelining).
> 
> adding pipelining support would not be difficult to do, actually.

I noticed that, indeed. Last time I was reading it, I did notice a few
things in its code that would make it difficult.

All in all, the ideas behind the 'imap4' way of working (with the IMAP
server) are indeed a lot better than the 'imap' code.

Maybe it would be a good idea to bring features like condstore and idle
to it? If there are some more people interested in this, I would
probably help out too. Unlike the stuff that I have put in the 'imap'
code, this should be done in a proper non-hackish way then, imo.

What I disliked most about Camel's 'imap' code, though, is the fact that
the sequences have to correspond to the array indexes of the
CamelFolderSummary. It sounds like it would have been more easy if that
was a key in a hashtable.

For example if a message got expunged that had a sequence value in the
beginning of the folder, it right now more or less means that the entire
folder has to be re-synchronised. While the majority of the local data
can be perfectly corrected in stead too.

Luckily very few people often remove things in the beginning of their
mail folders (since those E-mails are usually the older emails).

I have some ideas on having blocks of mmap data for CamelFolderSummary,
that for example contain ~ 1000 items per block, and having reference
counting per block.

That way I could create a vfolder-like feature that keeps only the
blocks alive that contain summary items that matched the query. In stead
of having to keep all the memory of each folder in the vfolder alive.

I have a prototype of this somewhat working, although done extremely
hackish too. So at some point I'm going to rewrite this first.

Another benefit is that the blocks will never have to be rewritten:
removals are simply marked until > 50% of the block is removed (and then
the entire block is rewritten), flag changes are stored in a different
file and on push-email events or a summary download, the latest headers
are kept in normal memory until there are enough of them to start a new
block.

Rewriting the summary file truly is a hit on performance on some
devices. On Flash it also introduces some level wearing. Which is why
it's another benefit.



-- 
Philip Van Hoof, software developer
home: me at pvanhoof dot be 
gnome: pvanhoof at gnome dot org 
http://www.pvanhoof.be/blog