Re: config library. Was GNOME registry

[Andrew Morton <andrewm uow edu au>]

bob smith wrote:
> 
> I have put up a page.
> http://www.thestuff.net/libcfg

Is good!

A thought:

Applications should not directly open/read the local config database.
There should instead be a config server with which apps communicate
(CORBA).  The libCFG API would of course hide all this.  The server
would "own" the local config database.

Reasons:

1: This will be the same interface over which a remote management entity
can access the database - it's just another client.

2: Avoids race conditions (what if the d/b is partway through an update
when an app reads it?)

3: Provides an interface by which apps can be notified of changes to
their config.  Many apps won't _use_ this, but it should be there.

4: If the apps can modify the d/b (they should be able to, but
permissions will get tricky) then the well-debugged server can validate
the update.  This prevents buggy apps from trashing the registry.

5: If the app is not using notifications then the API is the same as the
one you propose with direct file reading.

6: This way an app's config can be in local files, on a remote machine
or calculated on-the-fly by a smart server somewhere on the network. 
It's all seamless and heterogeneous.

7: The server can provide the logging, authentication and backout
services.

8: The server (or maybe the libCFG layer) should know about multiple
data sources.  Some of the app's config could be in the local database,
some may be served by a server elsewhere.  In an enterprise situation
you may wish to have a centralised server for all client machines,
although this doesn't show a lot of confidence in your replication and
propagation mechanisms :-).


If we need to import/export to/from flat files then a trivial client can
connect to the server and do this.

Under this scheme I don't quite see where XML fits in.  The
client-server messages will be CORBA encapsulated binary objects, no? 
The database would only be XML if it was flat-file, which seems
inefficient.  I like the idea of using XML, but I'd have thought a
relational d/b talking CORBA would be more appropriate.


Bear in mind that it'd be great if this mechanism could allow us to
administer legacy config.  For example, consider, ummm, /etc/fstab. I
doubt if we can go and change getmntent, mount, nfs, swapon, etc to use
libCFG in a hurry, so someone would need to develop the config server
plugin which knows how to convert the server's fstab CORBA messages into
the format required by /etc/fstab, write out the new fstab and then run
'mount'.  Of course this is what the linuxconf modules do.

- Andrew.