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'
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 ..
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
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
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 n
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.
These are the files Camel needs from libedataserver. Nothing more,
nothing less:
e-trie.c, e-iconv.c, e-memory.c, e-m
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
> > libe
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 ca
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
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? Cam
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 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? T
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 E
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 re
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 us
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.
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 :-), an
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 C
18 matches
Mail list logo
