config daemon/library for 4.6

[Brian J. Tarricone]

Nick Schermer wrote:
>>> 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.
> 
> Remember that plugin can have a different read and write location.

What do you mean?  A plugin would read settings from one location and 
write to another?  Why?

> And plugin settings are already removed when you remove the plugin
> from the panel (the unique id will never be generated again),
> therefore I'd like to have a xfconf side way of removing the data. It
> doesn't matter if it's *fast* or not.

Er, no they aren't, unless you've changed this in SVN.  I have loads of 
stale config files in ~/.config/xfce4/panel/ from plugins I've removed.

>> 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've vote for _property_remove in dbus and _channel_remove clientside
> if that also cleans the channel_name (with a file backend: not only
> emty the file, but also remove it).

Sounds good.

>> Does it matter?  I left out the error returns for simplicity.  Really,
>> how are they useful?
> 
> Error handling could be useful and you don't _have_ to use it. It's
> just a good way to allow communication between the xfconf backends and
> the user, when needed.

True, but I don't see how these errors would be useful to the user:

1.  A problem with the xfconfd daemon.  Well, "we can't talk to the 
daemon" is about the only error message you're going to get here, which 
isn't so useful.  If config files are corrupted, that's a daemon error, 
not a client library error.

2.  Property doesn't exist on Get().  This isn't really an error, and 
the API provides for fallback values when the property doesn't exist. 
If you really must know if a property exists or not, there's 
xfconf_channel_has_property().

3.  Property doesn't exist on Remove().  So what?  The result of the 
operation is the same: the property is not in the config store after 
calling remove().  And if remove fails for another reason, is the client 
going to care?  I don't think 'providing a message to the user' (why 
would you want to, anyway?) is a good reason to have error returns.

> Personally I'd like to know when something failed and better tell the
> user something when wrong (no write permissions with a file backend),
> before he/she loses information, but maybe I'm a bit GError addicted,
> duno, /me just likes it ^_^ and IMHO it's the cleanest wait of error
> handling in a library.

All the _set() functions return a gboolean.  The *reason* why the set 
failed isn't so important.  For GUIs that wish to disable GUI elements 
for settings that have been locked by an administrator, there will be 
API for this: xfconf_channel_is_writable() and/or 
xfconf_channel_property_is_writable().  You're not going to set out to 
determine if a property is writable by trying to write to it; you're 
going to ask in advance.

I agree that GError is great for passing around error information when 
you don't have a GUI, but the point I'm trying to make is: the intended 
audience that I have in mind for the client library *doesn't care* why 
and operation failed when it failed, and in some instances may not even 
care whether an operation succeeded or failed.  I want to keep this API 
as clean and simple and easy-to-use as possible.  Error explanations are 
just extraneous noise for this application.

Now, if someone wanted to write an app that cares about getting GErrors 
back, the dbus interface provides them.  The XfconfChannel API is really 
a pretty thin layer on top of the dbus interface and it's not very hard 
to just take generated glib bindings header for it, and call (e.g.) 
xfconf_client_set().

	-brian