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

2006-07-22 Thread Philip Van Hoof
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

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

2006-07-22 Thread Ross Burton
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

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

2006-07-21 Thread Tor Lillqvist
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

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

2006-07-20 Thread Philip Van Hoof
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

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

2006-07-20 Thread Philip Van Hoof
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

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

2006-07-17 Thread JP Rosevear
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

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

2006-07-13 Thread Ross Burton
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?

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

2006-07-13 Thread Harish Krishnaswamy
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

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

2006-07-13 Thread Philip Van Hoof
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

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

2006-07-13 Thread Philip Van Hoof
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,

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

2006-07-13 Thread Ross Burton
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

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

2006-07-13 Thread Philip Van Hoof
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

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

2006-07-13 Thread Frederic Crozat
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

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

2006-07-12 Thread Philip Van Hoof
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

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

2006-07-12 Thread Ross Burton
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,

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

2006-07-12 Thread Philip Van Hoof
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

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

2006-07-12 Thread Ross Burton
On Wed, 2006-07-12 at 17:39 +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. Cleaner

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

2006-07-12 Thread Philip Van Hoof
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