Re: [Evolution-hackers] strtok camel from evolution-data-server

[Philip Van Hoof <spam pvanhoof be>]

On Fri, 2006-07-07 at 08:26 +0100, Ross Burton wrote:
> On Thu, 2006-07-06 at 21:23 +0200, Philip Van Hoof wrote:

> Not strictly true.  From camel/ in EDS HEAD:
> 
> #include <libedataserver/e-data-server-util.h>
> #include <libedataserver/e-iconv.h>
> #include "libedataserver/e-memory.h"
> #include <libedataserver/e-msgport.h>
> #include <libedataserver/e-sexp.h>
> #include "libedataserver/e-time-utils.h"
> #include "libedataserver/e-trie.h"
> #include <libedataserver/md5-utils.h>
> 
> The MD5 code can be removed as I believe its in GLib 2.10 now (although
> its early for a hard dep on that).  The sexp, iconv, msgport and memory
> code is non-trvial and used in other libraries, so can't be just copied
> into camel.

The msgport stuff isn't that hard. I mostly took a look at that part to
estimate the "a few hours" part of my mail. About sexp and iconv I have
to admit I have no idea at this moment. MD5, as you said, is in glib (so
probably doable).
 
> > >From reading code I *know* camel doesn't have to depend on e-d-s at all.
> > It can very easily be cut-off from it. I could probably do this in a few
> > hours work.
> 
> By copying lots of source, yes.

Or by exploding e-d-s into lots of libraries? :)

> > The full e-d-s requires 23Mb disk space. Only Camel requires ~ 1MB disk
> > space.
> 
> Don't install the full EDS.  You'll note that the 770 only contains the
> addressbook code, and no groupwise/ldap/exchange support.  Yay for clean
> packaging.

ok. sounds very good.

> > Conclusion:
> > -----------
> > 
> > So or camel is going to be split from evolution-data-server, or I will
> > fork camel.
> 
> This sounds like fighting talk.  Should we arrange a street brawl?
> Shame this mail wasn't sent before GUADEC, a fight on the beach, fork vs
> split, would have been good.

Lol ;-). No. I really really prefer working together with upstream
people (although I understand that that might not always be easy).

Don't get me wrong here. Forking is the last thing I want to do. And
about putting up a fight ;), well you are right that it would have been
fun to do that on the beach at Villanova. Capoeira!

But ... I'll give some more details on my plans here. I'm really not
trying to upset people or trying to put up a fight. My intentions are
good (experimenting) etc etc ;-).

It's also that I recently learned about posix_madvise for my camel-
folder-summary.c mmap() idea. The only way, afaics, to make it possible
to at the right time invoke the right posix_madvise on the addr pointer
of the mmap, is to expose a new API to the CamelFolder:

	-> the behaviour of the program in relation to the addr pointer of the
mmap() would change from sequential to random (this is what
posix_madvise allows you to tweak) when for example sorting happens.
It's, however, ui code that knows when sorting is happening or is going
to happen.

So I'm fearing the results of these experiments are going to be
unacceptable for upstream camel. Actually, I would understand if it
would be unacceptable. If I try to put myself in the shoes of the
maintainer (is that fejj?), I think would have a hard time accepting
such API changes.

However. I'd like to experiment a little bit (for tinymail, of course)
yet don't feel limited by what upstream would or would not accept.

So it's two vectors. One is that I need to drag a lot e-d-s baggage with
me (but openedhand packages and maintenance might actually fix that,
thanks). And the other is that I would like to tryout things that might
not be acceptable for upstream camel.

... But I would really want to work together with upstream as much as
possible. If I would fork things, it would probably be a so called
friendly fork (like the eds-dbus).

> Packaging the libraries as separate packages is not a hack, it's the
> solution.  That way you only install what you need: libedataserver and
> libcamel.

The temporary solution or the solution? I'm still not really very
convinced camel shouldn't be a separate library. But then again, I'm
probably just (being) hard to convince ;). You are right that if
openedhand would maintain these packages well, it would really make it
much more easy for me to accept the solution. So I'm looking forward to
that (and I'm going to checkout the current stuff).



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