Configuration API

[C. Gatzemeier]

Wow, quite some thread going on here, hope I'll have the time to catch up, 
Now, just a second to comment on the "authority" ;-)

Am Monday 03 May 2004 11:24 schrieb Dave Cridland [Home]:

> 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 far as I can tell several (if not many) projects have followed this appoach 
at some time in the past, and it turned out not to be optimal. They consider 
other data as athoritative than the app-to-be-configured and do "on demand" 
translation. Among them yast and debconf  (IMHO, though it is allways 
stressed debconf is not to be used as a registry this topic keeps people busy 
just because the design *has* a separate data storage)

Those that have experience using those tools nonexclusivly probably agree that 
it might be better to avoid a "fork and reconstruction" of the authoritative 
config files.

Therefore I was thinking the "only generate a common representation for 
configuration when demanded" approach could be preferable...

Together with "applications that need notifications, have probably already 
chosen a backend that supports it." and "activation for other/traditional 
configs can be defined for and handled by the backend interface" (parser in 
most cases) it should be possible to provide a good feature set and be fully 
backwards compatible. IIRC it was said the complexity of having only one 
filebackend for a common representation versus several different filebackends  
wasn't too big and wasn't a too big concern in CFG neither.

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

Does seem as a somehow rather common mis-generalisation though. ;-)

Regards,
Christian


BTW: I have to admitt haven't read about ACAP before, but remember the 
protocol to access CFGs middlelayer actually has been or still is a greater 
concern for the developers, and has been somthing they wasn't quite sure 
about.