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 _______________________________________________ Evolution-hackers mailing list Evolutionfirstname.lastname@example.org http://mail.gnome.org/mailman/listinfo/evolution-hackers