Configuration API

[Sean Middleditch]

On Thu, 2004-04-29 at 08:56, Thomas Leonard wrote:

> > Some apps need to store complex data types, for example.  (think
> > structs, or maybe just associative arrays.)
> 
> Isn't this normally done with the key names directly? Eg, rather than:
> 
> 	/net/proxy = {ftp: "ftp-proxy.com", http: "http-proxy.com"}

Then we need a way to scan all keys under a particular path.  I.e.,
"what structs/subdirs are under /panel/objects/", since there may be
something like:

/panel/objects/123a4bc56/name = "blah"
/panel/objects/123a4bc56/type = "clock"
/panel/objects/acf75e12a/name = "foo"
...

> In any case, I'd prefer to have the backends just storing simple types
> (maybe just integer, string, byte-array) and let more complicated
> applications use whatever libraries they please to parse them (eg,
> treating a string as an XML document, or something).

No, because that makes administration hell.  That was one of the
problems with LR.  If you don't have types that support what we need,
each app will invent its own file format inside the key values, which
defeats the entire purpose of having a common API.

For one, you can no longer monitor or individually change particular
bits of data that are stored in those specially encoded XML/whatever
values.

For two, admins then need to learn many different formats, you need to
wirte all sorts of parsers to handle these formats, etc.  Tons of
complication put on both developers and administrators for no reason
given that the configuration system can do it on its own and save
everyone the pain.

> 
> > Is this API going to be only actual preferences, or do we also want to
> > store application state (window position and such) and data (recent
> > files?) as well?  If yes, the API needs to be able to handle the
> > oddities of each.
> 
> It may be that the 'ultimate' config system would be a filesystem with
> efficient storage of small files (reiserfs), automatic backups (svn),
> atomic commits of multiple files, networking, stacking (unionfs), change
> notification (distributed dnotify?) and user-space hooks (fuse) for
> ultimate flexibility.
> 
> However, we probably need to build something a bit simpler at first ;-)

Not so much simpler as something that actually exists.  The features you
listed above do not exist on many platforms, and even Linux doesn't
support those universally.  I for one won't use ReiserFS given its tons
of actual problems that make efficient storage of small files
worthless.  (Look at the current Reiser4 non-sense - needing special
syscalls to even handle POSIX attributes?  screw that crap.)

> I guess what we actually want is an API that:
> 
> - Lets us implement all the functionality of the GNOME and KDE systems
>   that is presently used/needed.
> 
> - Can be extended in the future.

Better we get it right the first time.  Otherwise we're going to get a
system up, that's going to have tons of problems "that can be extended
around later" and that's never giong to happen. GConf was an experiment
that has stuck us with production systems with a few problems.  Or look
at the current X discussions: it was always intended to be
improved/extended, yet it's take some, what, 15 years to do it?

We can get it right the first time if we plan, think it though
carefully, and don't just rush to get a simple system done now.  :)

> 
> The existing systems are already flexibly enough for the vast majority of
> uses. I think the reason projects outside of GNOME/KDE aren't using them
> isn't to do with lack of features, but more to do with (perceived) bloat
> from features they don't need (like change notification) or implementation
> details they don't like (eg, CORBA).

Take a look at the link I posted a few messages back regarding the
problems with GConf (as written by GConfs prime author).  We don't want
to just blindly copy the mistakes current systems made, we want to
improve on and fix those systems.

> 
> > Are schemas and data sanity/integrity checking mandatory, backend
> > specific, or something for the app to worry about?
> 
> I'd prefer it in the app (or app libraries). Some backends are likely to
> allow manual editing, anyway.

Most backends should allow manual editing.  One of the advantages of a
schema is that it can provide sanity checking for invalid edits.  It
also makes sure that when multiple apps use the same key that are
ensured to use the same format, as well as provide a central location
for identifying who owns which key, so two apps don't try to start using
the same key/path for different things.

> 
> > How will the API handle differences between per-user and per-machine
> > settings, system-wide and session-wide settings, and so on?
> 
> I think that ideally that wouldn't appear in the API at all. ie, the
> session manager asks for the key 'freedesktop.org/window-manager', and
> it's up to the backend to get a value appropriate to the current
> user/machine/system-wide-defaults.

That sounds good from an app point of view.  But say I want to write a
graphical configuration editing tool for administrators?  Should it be
backend specific, or capable of using all backends and thus configuring
th eper-machine/per-user/etc stuff?

> 
> > Configuration storage is a very complex problem.  There's a reason
> > nobody has it anywhere near right yet.  ;-)
> 
> True, but unifying the current systems and getting them more widely used
> would be very worthwhile, even without any fundamental redesigning.

It would be a waste of time, IMO.  Why write two new configuration
systems when we can just write one and keep it?

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