Re: 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