Re: [Evolution-hackers] Install E-D-S backends into separate directories?

[Milan Crha <mcrha redhat com>]

On Wed, 2011-01-05 at 12:13 -0500, Matthew Barnes wrote:
> Yes, but I'll write them.  They're nothing more than a bunch of
> GObject properties with simple get/set functions.  The marshalling of
> those values to and from key files is all handled transparently by
> ESource.
> 
> Writing those classes is monkey work, as you like to call it.  :)

Nobody likes monkey-work, neither code duplication, and as we are
talking about each backend for addressbook and calendar, then one can
imagine what that might mean. For example, will you write these for
evolution-couchdb, evolution-kolab and possibly many other 3rd party
providers, apart to all of included in eds itself? You may understand
why I dislike the idea.

I thought, from one of your first mails about this, that this code
duplication will be unnecessary, that the basic ESource will have a way,
different from the GObject properties, to get/set any property from the
ESource hierarchy. And what I thought was that it'll not be done through
GObject, but through its own API.

What I'm trying to tell is that the approach of GObject properties is
more limiting and adds more monkey work than an approach with special
get/set API on ESource itself.
	Bye,
	Milan