On Wed, 2006-07-12 at 19:13 +0200, Philip Van Hoof wrote:
> On Wed, 2006-07-12 at 17:00 +0100, Ross Burton wrote:
> > On Wed, 2006-07-12 at 17:39 +0200, Philip Van Hoof wrote:
>
> > > It's cleaner in my opinion :-), and I can more easily create a tar.gz
> > > release.
> >
> > Cleaner for what reasons?
>
> Because it will be more easy to pick which libraries you will use (in
> your application that integrates with the e-d-s framework).
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.
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.
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.
[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.
> The E-mails and, folder-summaries, state data and summaries of Camel are
> *not at all* being managed by Evolutions data server. It's simply
> totally unrelated to the Evolutions data server. It looks like even some
> Novell employees don't know that, probably cause it's being marketed as
> "one" package.
Calendar data isn't being stored by the addressbook server either. That
isn't a great argument.
[snip rant]
> 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.
Ross
--
Ross Burton mail: ross burtonini com
jabber: ross burtonini com
www: http://www.burtonini.com./
PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF
Attachment:
signature.asc
Description: This is a digitally signed message part