Dave Cridland [Home]
dave at cridland.net
Mon May 3 12:24:45 EEST 2004
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
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
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'
Potentially, yes. Or they may tacitly or overtly support other projects
providing these, or they may tacitly or overtly support a shepherd process
> 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
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.
More information about the xdg