The differences between camel-lite and normal camel

I know most people don't care. Yet with Camel being an LGPL project, I
feel morally obligated to give people my changes in a usable format like
a unified diff.

The people of this world are hereby encouraged to condemn, use, curse,
reuse, copy and merge it with their own stuff.

The differences include all the recent changes Matthew Barnes did
(EMsgPort, EThread and EMutex replacements), the for me successful mmap
experiment that I did a few weeks ago which significantly reduces memory
usage when using summaries, renaming of the library -- from "camel" to
"camel-lite" -- to explicitly avoid any conflicts, reordering of the
include and library paths to explicitly avoid any conflicts, removal of
any unused piece of code in libedataserver and converting of it to a
static library, the linkage of the camel libraries with this static
libedataserver and finally the fixing of "all" compilation warnings in

The result is a very small Camel (camel-lite) that can be both linked
statically and dynamically which uses modern glib features in stead of
the aging e-d-s infrastructure, which uses mmap for loading the
summaries and which reduces memory usage at various other places (but
some of that work is also available in upstream already, the mmap stuff

I've tested and compiled a libedataserver and Evolution that links with
this version of Camel. Everything worked out of the box (but you do have
to hack the build environment of evolution-data-server and evolution a
little bit). I haven't tested this with evolution-exchange. I will very
soon do that and a patch for it is available (just ask). I will also
very soon provide a patch for Brutus so that Brutus will also work with

Note that the delta of changes is going to significantly grow (it's
already quite large). I will, as noted before, keep posting relevant
differences to these mailing lists and will try to keep as much as
possible merge-able with the Camel in evolution-data-server. I can't,
however, promise it: My plans for camel-lite are indeed to make signif-
icant changes. Including infrastructural.

Expect memory usage to be squeezed a lot more. I have a few very clear
locations that can use a lot optimizations. Like the struct size of the
CamelMessageInfoBase type. Such changes are very unlikely ever going to
reach evo's HEAD (unless something changes at the core of the Evolution
development cycle) nor am I planning to wait any longer.

Criticism is welcome. Off this list please.

Philip Van Hoof, software developer at x-tend 
home: me at pvanhoof dot be 
gnome: pvanhoof at gnome dot org 
work: vanhoof at x-tend dot be -

Attachment: camel-lite.tar.gz
Description: application/compressed-tar

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]