Hi there,

I got notified that some Evolution hackers are interested in bringing
the features of camel-lite to camel. This is of course excellent news!

To ease this process, I pushed all the recent changes that happened to
camel, to camel-lite. These changes include the copyright's address
changes, the changes Matthew Barnes did on the BASE64 decoding, most of
the compiler-warning changes (although a lot of them had already been
put in camel-lite, of course), Kjartan Maraas's 0 vs. NULL changes,
Milan Crha's changes (set-label, compiler warnings, etc).

Using this changeset you can follow the changes to camel-lite:


Note about compiler warnings: camel-lite contains fixes for -pedantic
warnings. When making differences, you might find compiler-warning fixes
that you wouldn't expect with -Wall. Camel-lite right now has two or
three things that are problematic and not yet fixed for -pedantic:

 - Enumerations that exceed the size of an int, which are not allowed in
   ANSI C (or C99, I don't remember exactly).

 - Casting function pointers to (void*) which also isn't allowed (but I
   have no idea how else I can store them in a GHashTable, which is what
   Camel is doing at some locations)

Some of the changes to camel-lite might not be welcomed to camel. Among
them I expect the changes to camel-object not to be interested (some of
these changes cut one or two bytes from the CamelObject's size and put
some more and also less locking-on-signal-emissions in place). Others
are more clear like features that are just not interesting. And yet
others are just not done in a clean way.

On future plans for camel-lite: I'm interested in implementing QRSYNC
next to the CONDSTORE support. Although only one IMAP server already
supports this (Isode's Mbox).

Philip Van Hoof, software developer
home: me at pvanhoof dot be 
gnome: pvanhoof at gnome dot org 

Evolution-hackers mailing list

Reply via email to