Configuration API

[Thomas Leonard]

On Tue, Apr 27, 2004 at 11:40:59AM -0400, Sean Middleditch wrote:
> Why don't we come up with a list of use cases and needs for the
> configuration API first?  Then come up with an API that meets all those
> needs.

Sounds good. We've probably got most of the use cases from GNOME and KDE,
though. It sounds like we want to extend it to allow all apps (apache,
samba, gimp, etc) to use it. With a good API with pluggable backends, that
seems reasonable.

> 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"}

I'd expect to see:

	/net/proxy/ftp  = "ftp-proxy.com"
	/net/proxy/http = "http-proxy.com"

Lists are trickier, unless this is OK (can lead to gaps):

	/preferred-language/1 = fr
	/preferred-language/2 = de
	/preferred-language/3 = en

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).

> 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 ;-)
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.

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).

> 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.

> 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.

> 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.


-- 
Thomas Leonard			http://rox.sourceforge.net
tal00r at ecs.soton.ac.uk	tal197 at users.sourceforge.net
GPG: 9242 9807 C985 3C07 44A6  8B9A AE07 8280 59A5 3CC1