config daemon/library for 4.6

[Brian J. Tarricone]

Jannis Pohlmann wrote:
> Am Wed, 5 Sep 2007 14:55:43 -0400
> schrieb "Erik Harrison" <erikharrison at gmail.com>:
> 
>> On 9/5/07, Brian J. Tarricone <bjt23 at cornell.edu> wrote:
>>> Nick Schermer wrote:
>>>> Maybe it's also useful to have a function to remove a channel and
>>>> all the properties inside (for example when a plugin is removed
>>>> from the panel, the panel can ask to remove all the plugin
>>>> settings).
>>>>
>>>> gboolean xfconf_channel_remove (const gchar *channel_name,
>>>>                                     GError **error);
>>> That sounds reasonable.  Another option would be to just remove the
>>> channel when all properties are removed, but that's annoying.
>>>
>>> But really -- what application *ever* cleans up its settings on
>>> uninstall?  Plugins never do either.  Is this even necessary?  Yes,
>>> the store could get cluttered, but unused channels shouldn't impact
>>> the daemon at all (they won't get loaded if no one asks for them).
 >>
>> Panel plugins are a special case because the panel guarantees that
>> their configs don't step on each other or pull old settings. I suppose
>> the panel could simply provide the XfconfChannel object and pull the
>> same naming trick it does now with config files.
> 
> Exactly that is what I had in mind. Just provide a unique XfconfChannel
> to each plugin and that's it. It doesn't sound like a bad idea to
> cleanup old settings of plugins when they are removed from the panel.
> And after all, such an xfconf_channel_remove() function wouldn't cost
> much time to be written.

Ooh, I like that.  To avoid complicating the dbus interface, 
_channel_remove() may be client-side: it just does GetAll() and then 
Remove() on each property.  The daemon could have a policy that it 
removes a channel if it has no properties left.  This isn't optimal 
performance-wise (a round-trip per property), but it's not a common 
operation.  Should I care about optimising this, or just add a 
RemoveChannel() method to the dbus API?

(I think I want to change the dbus API so the method names are more 
descriptive.  GetProperty(), SetProperty(), RemoveProperty(), 
GetAllProperties(), RemoveChannel(), etc....)

>>>> The current api also lacks a bit of error handling, so errors in
>>>> xfconf_channel_remove_property for example
>>>>
>>>> gboolean xfconf_channel_remove_property(XfconfChannel *channel,
>>>>                                     const gchar *property,
>>>>                                     GError **error);
> 
> Do we ever need this function by the way? Removing a whole channel
> might make sense (where a channel bundles settings for one program),
> but removing single properties? 

I'm not entirely sure.  I could see an instance where there's an 
application that needs to do some sort of preferences migration on an 
upgrade might look for the presence of old values to determine if the 
preferences have been migrated yet or not.  But this probably isn't a 
common case.

> Concerning the error handling: IMHO Erik has a point with backend
> developers being in need to debug the side-effects of their code. On
> the other hand we really don't want to add a GError** parameter to all
> of the get/set functions etc.. Error handling like this is useful when
> dealing with critical resources likes files, but if we pass default
> values then we don't need detailled explanations about why and how a
> property could not be fetched (or stored - there a boolean return value
> or something similar will do).

Backend developers are not the target audience for the client library. 
'dbus-send' is an excellent debugging tool for them ^_~.

> With an ...is_writable() function we make it possible for applications
> to disable certain entries, check boxes or radio buttons. The
> application/client has to assume that the config storage does it's damn
> job - if not, just display an error message.

Yup, this is on my todo list.

	-brian