Re: [Evolution-hackers] Camel in evolution-data-server, a different proposal

[Philip Van Hoof <spam pvanhoof be>]

On Thu, 2006-07-13 at 10:24 +0100, Ross Burton wrote:
> On Wed, 2006-07-12 at 19:13 +0200, Philip Van Hoof wrote:

> This is only for the case of the developer who is both writing an
> application and developing the underlying libraries, and is also only
> using a subset of the libraries, right?  That is pretty much you.

Maybe I'm the only one. Maybe because it's not easy to do so?

> The Evolution hackers are using the entirety of EDS obviously, Chris
> Lord (Dates and Contacts developer) isn't developing the libraries (just
> using the packages I produce for Maemo), and although the 770 uses only
> the addressbook we disable Camel and Calendar at configure time.

> There is no reason why you can't just take the eds tarball, build
> packages, and use just libcamel.deb on Maemo, or any other platform.

But it's more work (and less clean) to put AM_CONDITIONALS in
Makefile.am files and funny if-then-else and pkg-config magic in
configure.in, than it is to simply make a new configure.ac file in
evolution-data-server/camel/ and cleanup the configure.in of eds itself.


> X has taken the modular route, but in that case the composite tarball
> was *huge*, and many parts of it hadn't changed for years.  There
> splitting it up into separate packages made absolute sense (although it
> did cause huge amounts of pain on the packages, LFS users still moan
> about the modular packaging on xorg-list).  I don't see how splitting
> EDS into ~10 library packages would help anyone apart from you, as you
> don't want to have a large source tarball for a camel package.

Adding a configure.ac to evolution-data-server/camel doesn't change
anything to the tar.gz being produced for desktops (except a few more
bytes in size, because we added a file).

> [snip]
> > At this moment, all those fall under the name of "evolution comma data
> > comma server". Some of these libraries (like Camel) don't necessarily
> > have "anything" to do with the Evolution data that is being managed by
> > the data server of Evolution.
> 
> "hyphen", not "comma".
> 
> EDS is a far better place for Camel than in Evolution itself, which is
> where it is.  EDS is a library for storing and accessing PIM data, and
> email is part of this.

I wasn't (am no longer) proposing to move "camel/" out of e-d-s. I was
proposing to put a configure.ac file in its directory. Moving Camel out
of evolution-data-server/ is not the scope nor point of this thread.

> Calendar data isn't being stored by the addressbook server either.  That
> isn't a great argument.

And I question ... do all applications that want to use calendaring (and
only calendaring) have to depend on most of the Evolution components?

Right now, if you translate that to Camel and E-mailing, it depends on
which distribution you have. On most Redhat based ones: yes. On Debian
based ones: no. Is there clarity? no. Is it making it more easy to
develop a pure "E-mail" application and to document which dependencies
you have (maybe even letting packagers share the same dependencies): no.

The list of reasons (all valid ones, it's not because *you* mark them as
rant that it also *is* rant) goes on and on and on.

> > Conclusion .. all this coupling with Evolution and Evolution Data Server
> > is making it harder for application developers to actually *use* the
> > provided functionality.
> 
> You are talking entirely from a packaging point of view.  Yes, it would
> be nice to have an option to at configure time disable the address book,
> or the calendar (I have the latter in eds-dbus).  Being able to enable
> and disable backends selectively would also be nice.  I'm sure patches
> for this would be considered.

Like adding a configure.ac to eds/camel ? ;-)


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