Re: [Evolution-hackers] Camel in evolution-data-server, a different proposal
On Sat, 2006-07-22 at 00:00 +0300, Tor Lillqvist wrote: on 2006-07-12 klockan 19:13 +0200 skrev Philip Van Hoof: 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. During the 2.6 development phase and the Win32 porting (spring 2005, roughly), many functions were identified that were duplicated (!) in the evolution-data-server, evolution and evolution-exchange modules (module in the CVS sense). They were kept in/moved to libedataserver, simply because that seemed to be the best place as everything else linked to it already anyway, and I didn't want to add yet another library. Yep. And the point that I tried to make was that copypasting this into a larger library that doesn't have a lot to do with the functionality being copypasted, makes the gateway to using this functionality (the library itself) needlessly more difficult (larget) for applications that use the functionality out of the scope with Evolution. Look at camel-builder-lite test. I identified six files that don't cross-use any of the other files in the libedataserver library. You don't have to change a single line in them. Just isolate them in the Makefile.am and recompile. https://svn.tinymail.org/svn/camel-lite-builder/trunk This, in my opinion, can alienate the shareable functionality from applications that could otherwise have used it in a shared way with Evolution. In the long term it could maybe alienate very good and nice shareable Evolution code from the community as well. That might maybe, who knows, result in fewer people using this awesome code. Maybe, you never know, fewer people caring about it. Which might, but I'm not sure, get us fewer people contributing enhancements back to Evolution. I have customers and end-users that are building mobile devices that will *not* come with contactbook nor addressbook functionality. Why would I want to ship a libedataserver that contains 1.5 megs of functionality that my Camel isn't using? The answer is rather simple: I don't want that: so, that's why .. camel-lite-builder, another hack. . . . (A little bit off topic and not technical) The vertical, mobile and embedded market. The different story: People who say that it's impossible to have a mobile user that doesn't want contactbook nor addressbook functionality, might not really understand the embedded and mobile world. Especially not the embedded world. It doesn't really work like that at all. Vendors of such devices want to make choices. They will define the price, in yes a pure sales way, based on this functionality. That's because people want choice. This is why WinCE is not as successful on devices as Windows XP on the desktop: people want their device to be their personal device. It must expose the functionality that they personally desire. Whether that is an injected feeling by a sales guy or not, doesn't really matter *at all*. I'm soon going to have customers that will ask me: I'm this software builder for a customer that wants a vertical application that integrates showing E-mails in a very specific way that are stored on their Exchange server. I only want the application to show E-mails that are tagged in a specific way. I don't see how this customer already needs contactbook and addressbook functionality. I would certainly understand that this isn't what Evolution wants. But people here *really* *ask* me to work upstream for the enhancements that I do to Camel for tinymail. Or ... don't they? Maybe you know these fancy cafes where you can get yourself a cocktail and where the waitress notes down your order on a PocketPC? It gets transferred (using a webservice over wifi) straight to the bar. When miss waitress has wrote down all the orders ... the drinks are already ready. We have those in Belgium. How does that device need contactbook or addressbook functionality? If it needs 2 MB more memory for functionality it will not use, the price of the hardware might go up drastically. Some of these businesses order 1,000ths of such devices. But functionality to show messages that the bar-guy sends to the girl: I can imagine *that* being important for their business. It doesn't have to be important. Contactbook and addressbook functionality might also be important. My point is: choice. Welcome to the vertical market. There used to be, even earlier, a module called gal (GNOME Application Library I think) containing a library libgal, which got scrapped (presumably because nothing except Evolution (and e-d-s) used it despite its name) from which some of these functions had been copy-pasted. In retrospect, perhaps scrapping libgal wasn't a good idea after all, maybe it should just have been renamed, to libevolution-and-friends or whatever? Somebody please correct me if my memory serves me wrong... -- Philip Van Hoof, software developer at x-tend
Re: [Evolution-hackers] Camel in evolution-data-server, a different proposal
On Sat, 2006-07-22 at 12:04 +0200, Philip Van Hoof wrote: I have customers and end-users that are building mobile devices that will *not* come with contactbook nor addressbook functionality. Why would I want to ship a libedataserver that contains 1.5 megs of functionality that my Camel isn't using? The answer is rather simple: I don't want that: so, that's why .. camel-lite-builder, another hack. As I pointed out before the 1.5M impact is due to statically linking BDB. If your target system has BDB, and frankly a huge number of devices have it, then dynamically link and libedataserver is nearer 100K. 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 signature.asc Description: This is a digitally signed message part ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Camel in evolution-data-server, a different proposal
on 2006-07-12 klockan 19:13 +0200 skrev Philip Van Hoof: 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. During the 2.6 development phase and the Win32 porting (spring 2005, roughly), many functions were identified that were duplicated (!) in the evolution-data-server, evolution and evolution-exchange modules (module in the CVS sense). They were kept in/moved to libedataserver, simply because that seemed to be the best place as everything else linked to it already anyway, and I didn't want to add yet another library. There used to be, even earlier, a module called gal (GNOME Application Library I think) containing a library libgal, which got scrapped (presumably because nothing except Evolution (and e-d-s) used it despite its name) from which some of these functions had been copy-pasted. In retrospect, perhaps scrapping libgal wasn't a good idea after all, maybe it should just have been renamed, to libevolution-and-friends or whatever? Somebody please correct me if my memory serves me wrong... --tml ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Camel in evolution-data-server, a different proposal
On Thu, 2006-07-13 at 11:35 +0100, Ross Burton wrote: On Thu, 2006-07-13 at 12:25 +0200, Philip Van Hoof wrote: 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. For what purpose? Camel depends on libedataserver. Small correction: It depends on e-trie.c, e-iconv.c, e-memory.c, e-msgport.c, e-sexp.c, e-time-utils.c, e-data-server-util.c, md5-utils.c which is compiled in libedataserver. These files themselves don't depend on anything other in libedataserver. I also have a clean configure.ac ready that will only build a Camel, and a set of Makefile.am's that will build a static libedataserver using only the listed files above. Stripped a fully functional Camel x86 build uses 315K for libcamel, 339K for libcamel-provider and 868K for camel-providers/* -- 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 Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Camel in evolution-data-server, a different proposal
On Thu, 2006-07-20 at 10:05 +0200, Philip Van Hoof wrote: On Mon, 2006-07-17 at 15:35 -0400, JP Rosevear wrote: I think you're only real example is camel, which shares code with the other pieces anyhow. Knowing is a good idea. Hrmm. After re-reading my own stuff, I apologise for the tone. I'm not afraid of admitting when I make a mistake. I'll rewrite: I think it's interesting to know on which code-pieces Camel depends. This will make future decisions and discussions about it more easy. For that reason I decided to investigate it a little it. It turns out only the following files are being used by Camel: e-trie.c, e-iconv.c, e-memory.c, e-msgport.c, e-sexp.c, e-time-utils.c, e-data-server-util.c, md5-utils.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 Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Camel in evolution-data-server, a different proposal
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: 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. ... and fragments the platform. 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. They have a lot to do with it. iMip for calendaring for example (really you want the imip direct mail fall back to happen in e-d-s, not the client). There was also an idea to tie in a unified account settings dialog so that exchange/groupwise/jecs could be configured in a unified manner. 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. There were plans to look at this. In fact I discussed such a scenario with Jeff last week. Speed was always a major concern however, but something like the disk summary branch might alleviate this. 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? I think you're only real example is camel, which shares code with the other pieces anyhow. -JP -- JP Rosevear [EMAIL PROTECTED] Novell, Inc. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Camel in evolution-data-server, a different proposal
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 signature.asc Description: This is a digitally signed message part ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Camel in evolution-data-server, a different proposal
On Wed, 2006-07-12 at 19:13 +0200, Philip Van Hoof wrote: 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. Which Novell employees ? 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. Evolution-Data-Server handles PIM data - (mail / calendaring / contacts information, journals) packaging them together *does* make lot of sense. I do not think you are suggesting that every library should be packaged separately, are you ? snip Conclusion .. all this coupling with Evolution and Evolution Data Server is making it harder for application developers to actually *use* the provided functionality. The current packaging *is* good for users and packaging systems. As for the application developers, you are certainly not the first one to tread this path. Ask Gaim. Clock applet. Contact applet. Open Office. Planner. Beagle. Philip - Nobody is any better with these long winding arguments back and forth. Can we get to the business at hand ? Let us spend our energies together on the camel-mmap patch instead. --Harish ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Camel in evolution-data-server, a different proposal
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 ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Camel in evolution-data-server, a different proposal
On Thu, 2006-07-13 at 15:58 +0530, Harish Krishnaswamy wrote: Evolution-Data-Server handles PIM data - (mail / calendaring / contacts information, journals) packaging them together *does* make lot of sense. I do not think you are suggesting that every library should be packaged separately, are you ? Well ;-) not should. But it would be nice yes. All of the libraries that require the server to run, however, do perhaps indeed belong to the same package / tarball. Philip - Nobody is any better with these long winding arguments back and forth. Can we get to the business at hand ? Let us spend our energies together on the camel-mmap patch instead. I agree. Nevertheless, it's my opinion that evolution-data-server can be better organised. It's, however, not blocking me. It's just annoyances. -- 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 Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Camel in evolution-data-server, a different proposal
On Thu, 2006-07-13 at 12:25 +0200, Philip Van Hoof wrote: 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. For what purpose? Camel depends on libedataserver. 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. So you've found a problem with the Red Hat packaging, in that it treats all of EDS a single library. File a bug with Red Hat, and notice that Debian, Maemo, and OpenEmbedded (at least) already have split EDS packages. In the scheme of things this is a very minor issue which effects very few people. I'd prefer to see effort spent on fixing bugs and memory leaks. 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 signature.asc Description: This is a digitally signed message part ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Camel in evolution-data-server, a different proposal
On Thu, 2006-07-13 at 11:35 +0100, Ross Burton wrote: On Thu, 2006-07-13 at 12:25 +0200, Philip Van Hoof wrote: 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. For what purpose? Camel depends on libedataserver. Being a developer, I can probably fix that chicken and egg problem in a few hacking evenings. So you've found a problem with the Red Hat packaging, in that it treats all of EDS a single library. File a bug with Red Hat, and notice that Debian, Maemo, and OpenEmbedded (at least) already have split EDS packages. I very much applaud what OpenEmbedded, Maemo, OpenedHand and Debian did in terms of packaging. It's indeed the right way. In the scheme of things this is a very minor issue which effects very few people. I'd prefer to see effort spent on fixing bugs and memory leaks. I agree it's a minor issue. But things can happen in parallel. This is why people developed round robin algorithms in schedulers :). Else the minor ones or very-low-priority ones never get any attention from the processing unit (because the large ones eat up exactly 100% of the processing units time). However, I do agree that we are putting to much of a discussion/fight on it. It should probably simply be a patch and a get-it-over-with commit. ps. Is there a beach at the Boston Summit? Maybe we can do a beach-fight about it? :-) (ps. I'm not yet sure if I will attent the summit). -- 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 Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Camel in evolution-data-server, a different proposal
Le jeudi 13 juillet 2006 à 11:35 +0100, Ross Burton a écrit : On Thu, 2006-07-13 at 12:25 +0200, Philip Van Hoof wrote: 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. So you've found a problem with the Red Hat packaging, in that it treats all of EDS a single library. File a bug with Red Hat, and notice that Debian, Maemo, and OpenEmbedded (at least) already have split EDS packages. Mandriva too ;) -- Frederic Crozat [EMAIL PROTECTED] Mandriva ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Camel in evolution-data-server, a different proposal
On Wed, 2006-07-12 at 17:14 +0200, Philip Van Hoof wrote: Okay, forking Camel is not what I want. Nobody wants that. It's not a good idea. However, it would be more easy (for me) if Camel would have its own configure.ac file. That way would it be more easy to do a 'make dist' of just Camel, I think. The evolution-data-server configure.in could very easily forward the configure stage of Camel using AC_CONFIG_SUBDIRS() I think it's even possible to pass variables from the first configure.in to the next configure.ac. And if not, I guess we can simply write-out a m4 file and m4_include() that one in the second configure.ac. For example in case you want to pass version information from a to b. What advantages does being able to dist camel on its own have, over simply packaging it in a separate package like OpenEmbedded and Debian do: $ apt-cache show libcamel1.2-8 Package: libcamel1.2-8 Maintainer: Takuo KITAME [EMAIL PROTECTED] Architecture: i386 Source: evolution-data-server Version: 1.6.1-0ubuntu5 Depends: libc6 (= 2.3.4-1), libcomerr2 (= 1.33-3), libedataserver1.2-7 (= 1.6.1), libegroupwise1.2-9 (= 1.6.1), libglib2.0-0 (= 2.10.0), libgnutls12 (= 1.2.5), libkrb53 (= 1.4.2), libsoup2.2-8 (= 2.2.92), libxml2 (= 2.6.24), zlib1g (= 1:1.2.1), libnss3 Description: Generic messaging library for evolution data servers The data server, called Evolution Data Server is responsible for managing calendar and addressbook information. 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. 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. 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 signature.asc Description: This is a digitally signed message part ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Camel in evolution-data-server, a different proposal
On Wed, 2006-07-12 at 16:30 +0100, Ross Burton wrote: On Wed, 2006-07-12 at 17:14 +0200, Philip Van Hoof wrote: What advantages does being able to dist camel on its own have, over simply packaging it in a separate package like OpenEmbedded and Debian do: It's cleaner in my opinion :-), and I can more easily create a tar.gz release. 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? 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? -- 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 Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Camel in evolution-data-server, a different proposal
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 Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
