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 Camel. 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 isn't). 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 camel-lite. 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 http://www.pvanhoof.be - http://www.x-tend.be
Attachment:
camel-lite.tar.gz
Description: application/compressed-tar