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: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] www: http://www.burtonini.com./ PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF
Description: This is a digitally signed message part
_______________________________________________ Evolution-hackers mailing list Evolutionemail@example.com http://mail.gnome.org/mailman/listinfo/evolution-hackers