Re: [evolution-patches] The differences between camel-lite and normal camel

[Jules Colding <colding omesc com>]

On Tue, 2006-10-17 at 22:35 +0200, Philip Van Hoof wrote:
> 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.

Excellent ;-)


> 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.

Looking forward to seeing it. Consider putting your changes behind
--enable-camel-lite (or --enable-eds-lite) defines. That is the right
way to do it IMHO. It will then also be easier to put some configure
magic in place if required to support an out-of-tree e-d-s branch.


> 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.

Good luck.
  jules