Configuration API

[George]

On Tue, Apr 27, 2004 at 03:59:22PM +0100, Thomas Leonard wrote:
> For the configuration system, are we agreed that we need a library API?
> 
> Without it, the system seems too inflexible. Eg, we either require every
> application to support remote database access, or we can't support storing
> configuration in remote databases.
> 
> If we make an API, then people can get started writing backends for it.
> Eg, someone could make a gconf backend and all programs using the API
> would get their settings stored using gconf. Someone else could make a
> Linux Registry backend, or a D-BUS daemon, etc.
> 
> The API would have to be desktop neutral, support getting and setting
> values, and notification (if the backend supports it). We have some good
> example APIs, such a gconf's (and I guess the authors of those systems are
> the best people to suggest something).

Note that any "desktop neutral" API will get per-desktop bindings, which will
get us weird chains such as

GObject Wrapper -> FD API -> FD daemon -> GConf API -> gconfd -> backend

wheras what really would be useful to be shared is the backend.  That is,
GConf is already an API for GNOME and I bet KDE folks are just as happy with
their own API.  As long as we can plug shared backends into the native APIs
then there is no need for an FD only API.

Basically it's all in the backends.  I bet writing some glue code to be able
to use one set of backends would be most useful here.  It would not tie anyone
to any specific API (people are already tied) either.

Of course as long as the backends just specify different ways to store
configuration information locally, the whole exercise is semi to fully
pointless.  The place where this is useful is backends that do something
interesting such as store configuration on a server, or some such.  Also
perhaps a bit of thought should be given to how many such different backends
would there be?  If only one or two, it'd be much easier to write separate
backends for the existing APIs.

So just require apps to support whichever API is native to them, and just
make sure that there either is a backend for that API that supports the
desired storage or make sure that an existing backend can be wired in.

This is all IMO only of course.

George

-- 
George <jirka at 5z.com>
   I finally figured out the only reason to be alive is to enjoy it.
                       -- Rita Mae Brown