On Mon, 13 Jan 2003, Ira Abramov wrote:
> Quoting Omer Zak, from the post of Mon, 13 Jan:
> > I agree that this is a good and worthwhile idea.
> > May I suggest that we start defining an API and a standard configuration
> > library, and start encouraging application writers to migrate to the new
> >library?
[... snipped ...]
> You need to support locking of several instances reading the same
> configs, possibly a few writing too... and then it starts to look likea
> database.
>
> daemons for the configuration of each application? now who configures
> the config daemons? :)
Depends upon the installation.
Some installations will use a configuration library, which maintains
simple configuration files. Other installations, which need the power,
will use daemons. The applications should be transparent to those
details.
Of course, config daemons will need their own configuration (first of all,
to tell which applications should they configure). In my eighth-baked
design I mentioned a master configuration file exactly for determining who
will supervise each application's configuartion.
> I like it lean and mean. instead of using unified config daemons, I
> say we stick to common, easely grokable formats. 2-3 archtypes that
> answer all our needs. apache, samba and bind should not have a
> different syntax, but daemon is an overkill of the other extreme.
The API should be lean and mean. But behind it we can put whatever fat
daemons and hungry tigers the installation needs.
> what are the chances this will happen in this decade? very slim, but
> good luck :)
With a reasonable migration path (i.e. allowing each application also the
option of using its legacy configuration mechanism), this should be
achievable.
--- Omer
WARNING TO SPAMMERS: at http://www.zak.co.il/spamwarning.html
=================================================================
To unsubscribe, send mail to [EMAIL PROTECTED] with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]
