Configuration API

[Dave Cridland [Home]]

On Sun May  2 09:48:47 2004, Lars Hallberg wrote:
> Baris Metin wrote:
> 
>> In my opinion, a configuration system/API must be system wide. But I
>> don't think all software developers will accept a unique system/API
>> easyly. So maybe, regular configuration files can also be a backend?
>>  
> All apps don't need to use the API to read ther config, but ther need to be 
> a backend for ther config format so config tools can read and change the 
configuration!
> 

See Config4GNU, which does precisely that.

However, you're adding in a healthy chunk of complexity, there - you're 
suggesting that different portions of the configuration namespace can have 
different backends.

The alternative, as I've mentioned before, is to manage these systems 
externally, by having a shepherd process that handles the data and 
notifications from the common backend by rewriting configuration files and 
making those changes happen (by the almost-ubiquitous HUP, or restarting 
processes, as appropriate.).

As an aside, I once worked for a guy who thought that HUP actually was a 
'reread your config' signal. It was really funny when he made that assumption 
with the shell he was using. :-)

> 
> If this API get som use, say Gnome and KDE, app authors might start 
> providing and updating ther backends, regarless if they use the backends 
themself for reading ther config - just to integrate nicly with the 'standar' 
config tools!
> 

Potentially, yes. Or they may tacitly or overtly support other projects 
providing these, or they may tacitly or overtly support a shepherd process 
project.

> 
> The benefit from using the API in the app is that it becoms easy to replase 
> the config format or switch between lokal file store and network config 
deamons. When a set of solid implementations exists, it will probably be 
natural chose for *new* apps. But only apps needing som extra features like 
notification is likly to *change* to use the API. Stuff lika postfix, bind 
and apache is not likly to be first in line to cross over :-)
> 

Or, indeed, ever convert at all. Bear in mind that it's pretty trivial to 
stuff all the data for postfix's maps into a configuration store, but 
equally, when I looked seriously at doing that, I realised it was easier and 
better to simply use existing hash files and rewrite them on notifications.

In the case of Bind, I can't actually see Bind ever converting to a new 
configuration store, but equally, I can see people developing a shepherd 
process (or plugin for one), very rapidly.

Config4GNU, as I understand it, provides a huge amount of code already that 
can be used for this kind of thing, albeit it's wholly against the spirit of 
keeping those files as authoritative.

> 
> I think it is important to have the same API in two positions. Between a 
> backend for a given fileformat (or whatever) and a config deamon/app *and* 
between the config deamon and config tools/app (or rather, between the config 
tool/app and the library talking to the config deamon). That way You can 
bypass the config deamon and directly use the backend for a given fileformat. 
That may be needed for robustnes or on system wher no config deamon runs/is 
not started yet when the config needs to be readed!
> 

There will always be times when a given configuration system is unavailable, 
and some configuration systems make no sense without a daemon running 
somewhere.

A possible exception would be something like LR operating on the root 
filesystem - that implies a specialist filesystem used as the root fs, though.

Examples, however, of the former abound - LR operating on a non-root fs 
during boot, anything which requires libraries or data not present on the 
rootfs, etc. Network orientated configuration systems.

Examples of the second include all the network orientated systems, and many 
of the more complex local ones, too.

The only way to generate robustness, therefore, is to duplicate the 
configuration elsewhere, in some format that's known to work.

Luckily, we have such a format - many of them, in fact. We've got /etc/fstab, 
for instance. The data in that file may well have come from 
ACAP/LDAP/GConf/etc, but the file itself can exist, and can be edited in 
emergencies by any UNIX admin.

I appreciate that implies that a change to, say, the partition used to /usr/ 
would imply a reboot, but I think it does anyway.

Dave.