Re: strtok camel from evolution-data-server

On Thu, 2006-07-06 at 21:23 +0200, Philip Van Hoof wrote:
> Most Evolution people already know this. This is just the E-mail you
> guys have been asking about (well, actually most of you guys asked me to
> make a bug in bugzilla).
> 
> 
> The one laptop per child project, Nokia (maemo) and maybe sooner or
> later other vendors like PalmSource are getting more and more interested
> in tinymail.
> 
> Situation:
> ----------
> 
> Tinymail depends on Camel. Camel gets shipped with e-d-s. Tinymail
> doesn't use *any* of the other e-d-s softwares, libraries nor its data.

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.

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

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

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


> Hacks like packaging tricks:
> ----------------------------
> 
> I AM NOT going to require packaging tricks. Packaging tricks are hacks.
> I don't do hacks. Hacks are ugly. Hacks are win32. I didn't come to the
> opensource community to get myself stuck in hacks.
> 
> I strongly disagree with hacks. I don't support hacks. I will not use
> hacks. I will fork if I'm forced to use hacks.

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.

-- 
Ross Burton                                 mail: [email protected]
                                          jabber: [email protected]
                                     www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF

_______________________________________________
Evolution-hackers mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/evolution-hackers

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQBErgy5LQnkR9C0M98RAjWeAKDfr+40cwAbCr93+sWP1Oddin7d2QCfdiab
JYvrS8WB7a8Gjw4PVBO8UI4=
=0vNK
-----END PGP SIGNATURE-----