On Sat, 01 Feb 2003 14:46:10 -0800 "Matt Schalit" <[EMAIL PROTECTED]> wrote:
> > > Chad Carr wrote: > > On Sat, 1 Feb 2003 12:16:10 +0100 > > > > 1) a centralized configuration "database" and "api" for adding and > > removing system configuration parameters, > > > When using a centralized config-db (a good idea), how do we deal with > a new release of a program, let's say ntpdate? > > a. Do we have to package it up and modify it's files so that > /etc/ntp.conf uses config-db variables? The config-db is only itself. The templating system is used to transform the "abstract" values in the config-db to the format of each package. > b. Would the package have to include a manifest of variables > that go into the config-db and their default values? Yes. It would then fire a trigger which tells the templating system to re-make its configuration files. Also, because the triggering system is anonymous a completely loosely coupled, any program can "install" a trigger handler for a given trigger, i.e. if a program needs to know when the ip address of a given interface changes, it may install a script for that trigger which will modify _its own_ config files. The entity that fires the trigger knows not who is listening, nor does it care. The trigger is defined by the guy that fires it; everyone else plays along (only if they want to!) > c. Once the package's alterable files are made config-db aware, > and once the config-db is sourced, what additional perl or > scripting is needed? This technique is insufficiently decoupled from the back end config-db. Any package that utililizes the config-db directly is headed for trouble. It should only be accessed through the api - data hiding, you know. That way, the data itself can be transformed as it is moved in and out of the backend data store, if need be later in the project without changing the interface. Also, the config db is not a simple shell fragment; it must be multiple files that can be "dropped" into a filesystem hierarchy then accessed as nodes or trees. This allows the representation of complex data structures such as those needed for defining routing, traffic classification, etc. The api must be very smart in the way that it delivers these data structures. -- ----------------------------------------------------------------------- Chad Carr [EMAIL PROTECTED] -----------------------------------------------------------------------
msg06098/pgp00000.pgp
Description: PGP signature
