[xfconf] Implementing Schema's / using GSettings

[Andrzej]

On 01/20/2012 10:05 PM, Nick Schermer wrote:
> My opinion:
>
> I don't see any advantages in integration schemes in the settings
> backend of xfconf, or the daemon.
>
> If packages provide some sort of xml format to 'describe' the channel
> is fine, we can even add some new api to libxfconf to 'work' with the
> schemes (separate from XfconfChannel) (GType xfconf_scheme_get_type
> (XfconfChannel *, const gchar *property) and gboolean
> xfconf_scheme_get_int_range (XfconfChannel *, const gchar *property,
> gint *max, gint *min), things like that).

Well, that's really adding a schema to xfconf, which isn't a bad idea 
IMHO, provided we need this functionality. You're right, this is all 
about the API, storage is secondary but:

- we need _some_ storage in order to deploy this feature.
- we should standardized on it early (in order to avoid migrating data 
further down the line).

As for the actual implementation, how about allowing applications define 
their own custom data types (enums, integer ranges etc.)?

> But checking the props set
> by xfconf_channel_set_* against the scheme is a bad idea imho.

Not so "bad" as "unnecessary". The user has access to the backend so the 
data in it cannot be trusted anyway. Also, for security reasons the 
application should check the data coming from xfconf (someone could have 
e.g. substitute a different library for xfconf). So, I agree that the 
schema should be used only for the user's convenience, not for ensuring 
data integrity.

> Regarding porting: I don't see any real advantages of using dconf
> maybe there are small ones, but developers can mostly work around
> those: users on the other hand always have problems with setting
> migrations, so the message is: never do this until it is !!_really_!!
> needed.

Oh my, I've just read what dconf really is. Forget everything I said 
about moving to it - the whole idea of keeping configuration (mind you, 
configuration, not data) is IMHO brain dead, and the argument about 
efficiency is bogus (as if reading an XML file at startup was a 
bottleneck). If anything, I'd like the backend to become more accessible 
and flexible - for example to enable centralized configuration management.

BTW, if we really wanted to have a binary backend (which I don't), it'd 
be better to use something like sqlite - at least it comes with plenty 
of tools and bindings to manage the data.

Andrzej