Re: [Evolution-hackers] Might be a generic ESourceExtension useful?

[Milan Crha <mcrha redhat com>]

	Hi,

On Tue, 2013-02-05 at 06:32 -0500, Matthew Barnes wrote:
> On Tue, 2013-02-05 at 08:51 +0100, Milan Crha wrote:
> > After a little discussion with tristan on IRC, not a generic
> > ESourceExtension, but an API added directly to ESource, similar to
> > "property" API on the old source.
> 
> Those arbitrary string properties from the old ESource API are precisely
> what I wanted to AVOID by introducing ESourceExtensions.

That's why I call them "well-known" properties. There is nothing wrong
about them, they are all around us. Like in networking, CalDAV, ...

> The point of ESourceExtensions was to:
> 
> - Break settings into logical groups.
> 
> - Document what each setting is for, its data type and default value.
> 
> - Keep common settings consistent in name/type/default across backends.

The proposed change/addition doesn't break anything of the three above,
from my poor point of view. I'm fine with the third as you did it, those
real common properties are great to be in a common API and
libedataserver ESource extension structs, that's all fine. One could
still be lazy and use well-known name API to set values of common
properties, no doubt, but only on their own risk. On the other hand,
when accessing backend specific properties, then they should not reside
beside those common extensions.

> The code duplication in Evolution was meant to be temporary.  The long
> term solution, which I simply haven't had time for yet, is to move all
> that backend-specific configuration widgetry into E-D-S.

Hmm, why was done the API break with the libedataserverui movement to
evolution then? I miss here some point, right? In any way, code
duplication (especially in this form) is wrong, while well-known names
are not. I believe. That's why I brought out this idea, in a hope to be
useful and if more people will think about it, then something useful may
come out. At least most people are using this API now.
	Bye,
	Milan