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
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
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
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
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
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
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?
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
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
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,
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
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
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
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,
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
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
16 matches
Mail list logo
