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

[Harish Krishnaswamy <kharish novell com>]

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