Configuration API

[Sean Middleditch]

On Thu, 2004-04-29 at 12:13, George wrote:
> On Wed, Apr 28, 2004 at 05:41:55PM +1000, Jeff Waugh wrote:

> > The most troublesome bit is the configuration semantics wrt keys/values and
> > schemas and so on - you're going to define all of that with the backend API?
> > I'd be very surprised if the GNOME and KDE semantics were not incompatible
> > to begin with.
> 
> But that does not matter much.  As long as you don't expect to access weird
> KConfig keys from GConf or vice versa.  For keys that are to be common,
> they'd have to share some semantics.  Making sure we have the same
> semantics would be nice, but I think pragmatically irrelevant.  If the goal
> is to be able to say use LDAP, then we can use LDAP even though KConfig and
> GConf use it slightly differently.  However from the sysadmin standpoint,
> there should be a single place to say "I want everything to use LDAP on this
> server."  I think that's a reasonable goal.  That I won't be able to set KDE
> keys with gconf-editor?  Who cares.  IMO, that's a would-be-nice kind of
> feature and not a requirement.

Actually, that's exactly something we should aim for with any new API. 
If we're gonna go for it, let's do it right, not make yet another barely
useful half-assed system.  ;-)

For starts, the API should support a single set of unchanging low-level
types.  Integer, boolean, float, string, list (do we want these to be
free form, or specify "list of string"?), and struct/associative-array. 
If you have data that can't actually fit into that kind of model, then
as a last resort you can store it as a string in some other special
format.  Pretty much every value put in here needs to be human
readable/understandable, though.  If we have a backend like LR, I should
be able to open one of those key files as get to work.  If we have a
backend like GConf's, I should be able to open up my text or XML editor
and modifier things.  Tools like gconf-editor are just conveniences;
there shouldn't be a requirement for a specific tool to be able to edit
key values; just perhaps tools to extract and set values in a
backend-agnostic fashion.  (Which the API is intended to facilitate, of
course.)

The problem we come up on next, as Jeff was getting at I believe, is
that just because we have these concrete basic types doesn't mean
everyone will use them the same way.  Take for example a color entry. 
Maybe one app stores it as three different integers for red, green, and
blue.  Maybe another uses an HTML-style hex string for the colors.  etc.

This is a good place for specification (which has no need to be codified
in the API) to step in.  I.e., we provide this API and programming
interface for backends.  We also provide a document of "freedesktop.org
approved formats" for storing common data types.  I.e., this
specification might say that "All colors must be stored as hex-encoded
<string>s as specified in the following W3C standard..."  We can then
provide names for these formats.  A schema might then specify
type=string format=color.  A graphical editor like gconf-editor might
see the format being color and put a color picker in its UI.  On the
other hand, if it sees a format it doesn't recognize (say,
x-gnome-panel-id) or the format is unspecified, it can use the default
for the key type (string).  This way any value can be edited through
gconf-editor, and the format standard could be used to allow graphical
editors to provide more specialized interfaces.

These schemas can even be used in app-specific preferences windows.  For
example, say we have a web browser and it has a key (an integer) which
maps to an enumeration controlling some behaviour (load all images, load
images from same server, do not load images).  The schema could specify
the format as an enum with values 1, 2, 3 and labels "All Images",
"Images from Server", and "No Images".  (The labels could even include
translations.)  This will make gconf-editor look a little cleaner for
this specific setting.  But the browser preferences window could also
use this information.  This way, the developer needs only change their
code that uses the preference (the image loading check) and their schema
file; their UI maps accordingly.  It reduces the effort put into a
preferences window, reduces the chance of things getting out of sync,
keeps documentation/translations in one place instead of two (or more),
and so on.

Best of all, both schemas and format types could be optional. 
Developers that don't want to do the extra effort of using either of
those aren't forced to.  They just read/write keys and go about their
life.  The more robust and polished software can use them however to
great effect on usability, maintenance time reduction, and robustness.

> 
> George
-- 
Sean Middleditch <elanthis at awesomeplay.com>
AwesomePlay Productions, Inc.