config daemon/library for 4.6

[Erik Harrison]

On 9/4/07, Brian J. Tarricone <bjt23 at cornell.edu> wrote:
> Hey guys,
>
> Just spent a few hours hacking together a config daemon and library
> sorta somewhat based on Jannis' spec[1].
>
> I changed the name to 'Xfconf' to avoid confusion with the old MCS
> system and libraries.  The dbus interface is basically the same with a
> couple cosmetic changes and some functional changes to the GUI-related
> stuff.  You can take a look at my interface definition at [2].
>
> It's not complete.  It compiles, but there's no configuration store
> backend (well, there is one, but the get/set parts aren't implemented
> yet).  The client library should be functionally complete (though I'm
> not sure I'm happy with the API yet), and the daemon runs but doesn't
> really do all that much.
>
> You can take a look at what I have so far in my sandbox svn repo[3].
>
> The client API has a bunch of functions for getting/setting properties
> that look sorta like this:
>
> gboolean xfconf_channel_get_int(XfconfChannel *channel,
>                                 const gchar *property,
>                                 gint *value);
>
> A few open questions:
>
> 1.  I don't really like this all that much, but I want an API where you
> can tell from the return if the property was or wasn't in the config
> store at all (in this case, by the gboolean return type).  Any thoughts
> on a better way?
>
> 2.  I also wonder if we need a way to remove properties entirely?

I can imagine wanting to distinguish between "unset", and "set to
something essentially empty". On the other hand I can't come up with
an actual example.

>
> 3.  Would the model used for XfceRc work better?  XfceRc doesn't have a
> true/false return, but instead has an extra 'fallback' parameter which
> gets returned instead if the value isn't in the config file.  This
> works well in situations where you want to have a default value if one
> isn't set yet, without having a bunch of if/else trees.
>
> 4.  There's a string list property API that I'm not thrilled with.
> Another option is to be HAL-like, and have list append/prepend/remove
> functions instead of just a single set function.
>
> 5.  Do we even need a string list property API?
>
> 6.  I plan on adding a generic set/get pair to the API so you can set
> (semi-)arbitrary GValue types.  Useful?
>
> 7.  I plan on adding a simple client-side transaction type thing where
> you can start a transaction, and then anything you change gets queued
> until you end the transaction, after which everything is sent.  Does
> this seem useful?  Also, obviously a client-side transaction system
> isn't atomic since it will send over each property change one by one
> upon commit.  Does this reduce the usefulness?
>

To my mind this makes it utterly useless. My only use for a
transaction is in the case of an all or none cluster of property
changes. It's not just the danger of a crash leaving the data in an
inconsistent state - I might use a transaction to avoid a race
condition if my application depends on A = X if B = Y.

In previous discussions, no one has actually come up with a use for
transactions, just that they can imagine wanting them for
completeness, or in some vague future. If no one needs it why
implement a finicky half solution?

> 8.  I'm planning on adding a special read-only backend that can be used
> to seamlessly migrate over all old MCS settings, but I haven't quite
> decided how I want to do it yet.

Would this put the migration up to the application, or would old MCS
data become transparently available via Xfconf? I can see pros and
cons to both. But I tend to prefer transparent migration, so there is
the least dependence on independent developers to write migration
code.

>
> 9.  There's no GUI in the daemon; in fact, it doesn't even init gtk.
> I'd like to keep it this way.  The current settings manager button
> table thing should be implemented as a separate helper app, and the
> dialog windows for all the settings dialogs should be implemented in
> the applications that need them, and will provide a way to run them
> using the .desktop file method in Jannis' spec.
>
> 10.  I'm not sure what to do with the XSETTINGS stuff.  This would
> require X11 stuff in the daemon, which I'm not happy about.  One
> possibility is to have a separate XSETTINGS daemon that is just another
> Xfconf client and watches for property changes for stuff it needs to
> set XSETTINGS properties for (like gtk theme, icon theme, etc.).
>
> 11.  In theory, dbus activation will take care of starting the daemon
> as needed, but this isn't set up yet.
>
> I'm sure there are other questions in my head, but I'm too tired to
> pull them out.  Any other thoughts/comments/criticisms?
>

None that I can think of at the moment. But I'm sure we can churn some up.


>         -brian
>
> [1] http://lunar-linux.org/~jannis/mcs-design-proposal.txt
> [2] http://svn.xfce.org/svn/kelnos/xfconf/trunk/common/xfconf-dbus.xml
> [3] http://svn.xfce.org/svn/kelnos/xfconf/trunk
> _______________________________________________
> Xfce4-dev mailing list
> Xfce4-dev at xfce.org
> http://foo-projects.org/mailman/listinfo/xfce4-dev
>


-- 
Erik
"If you want to go somewhere, goto is the best way to get there." - Ken Thompson