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). > > > Before you can dist it as a separate package you'll need to remove the > > > use of libedataserver. That might not be possible or realistic, so I'd > > > attempt that first. > > > > Or do all the libraries in evolution-data-server with their own > > configure.ac? > > So you are proposing the following library packages: > > libedataserver > libedataserverui > libebook > libedata-book > libecal > libedata-cal > libgroupwise > And then binary packages for the Groupwise helpers, the Exchange > helpers, and the server binaries themselves. Yeah. Sounds perfect. Looks very clean. 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. 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. The ideal situation would be that most of these components would be reusable by application developers that don't have to use the Evolution data server at all. Why glue it? It simply looks like Evolution developers didn't know where to stack all these Evolution libraries. And thought .. oh, we already had this "Evolution data server" thing .. lets simply put it there. It's not good a solution, imo. "A library is a library". We have package systems (like yum and apt) to solve the dependency problem for users. And you see that distributions like Debian have to re-split it up anyway. > I'm also not sure where the backends would go in this scheme. Perfect example! ;-) It's actually for the backends why I would like this. At this moment it's not very easy to build a Camel provider for a mobile device for Exchange. Mainly because in order to compile it, I have to get a lot non-Camel related things compiling as well. Or I basically have to insanely patch the Makefile.am's and configure.ac file of evolution-exchange just to build its Camel provider. Why is that? In the end, I'm really only interested in the Camel provider! I don't want to implement some Evolution widget or pane for Exchange, nor do I want to implement calendaring support or whatever, if I just want to create an E-mail client for a mobile device that can show the user his Exchange mailbox. I don't even care about this evolution- data-server binary. Nor do I care about any other but the Camel library. Yet ... I have to do all these insane things just to get the Camel provider of evolution-exchange working on Maemo. Conclusion .. all this coupling with Evolution and Evolution Data Server is making it harder for application developers to actually *use* the provided functionality. > No, I don't think that is a good idea either. > > > If you find large bits of code that are only used in camel and are > > > currently in libedataserver, I'd propose moving them into camel: > > > libedataserver could do with slimming down. > > > > For example EMsgPort, is that used by something else but Camel? > > By the magic of grep, libedataserverui/e-passwords.c uses e-msgport.c. > -- 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 _______________________________________________ Evolution-hackers mailing list Evolutionfirstname.lastname@example.org http://mail.gnome.org/mailman/listinfo/evolution-hackers