Configuration API

[Lars Hallberg]

Dave Cridland [Home] wrote:

> On Sun May  2 09:48:47 2004, Lars Hallberg wrote:
>
>> 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.

Yeh, idealy, Config4GNU can cross over to the same API for ther backends :-)

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

Yes, that more of an implementation detail (large ditail I admit). Such 
shepherd process can use the same API and backend plugins to scan and 
generate the diferent config files!

Other implementation can use the different backends direktly to keep the 
'old style' textfiles 100% actoriative all time!

Think the API must be avere of the need of activation on (the config 
tool users) demand for apps not avare of notifikation.

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

Idealy, that would be the same thing!

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

The nice thing is that they can integrate nicly without ever converting. 
As You point out. Ther are strong reasons for some apps to rely on only 
on files in /etc/. But we still want those apps to be configurable thru 
our nice new GUI :-)

>
> 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!
>
A smale point here - if You chose to use the plugin for Apache config 
file format directly, You will only gett access to Apache namespace, but 
thats good enuf for Apache :-)

I can see som use for a small lib that can load a few backends and 
present them thru one instance of the API. That way a app neding to read 
(and possably alter) a few config files in different format can do that 
thru the API without the need to rely on any config deamon.

In the case of altering, it might lead to allot of stress for a shepherd 
process. Some filelevel locking cheem might be needed :-/

/LaH