Re: PROPOSAL: Just say no to database based admintools - Use parsers
--------
[Sigh, for (n+1)th time, no need to Cc:]
On Wed, Jul 9 1997 12:00 +0200 Andreas Jellinghaus writes:
> > > In contrast, the article pointed out
> > > that MS Word has become this enormous, do everything, buggy piece of
> > > bloatware (my exaggeration). I see the dtxtdb as a centralized
> > > duplication of /etc (i.e., bloatware). I have lost interest in the idea.
>
> again : my goal for dtxtdb is to store the OPTIONS= lines of all
> /etc/init.d scripts, that's all.
>
> dtxtdb has nothing to do with the "build a huge database" discussion.
> please, do not refuse the dtxtdb concept, because of some "dreamers".
I agree 200%.
> and for the other people : if you don't talk about the dtxtdb concept,
> please make it clear to everyone, that you do not.
Yes, please.
> David Frey wrote :
> > We haven't settled the issue yet what to do with the standard configuration
> > files as /etc/hostname, /etc/uucp/*, /etc/smail/*, etc.
> >
> > Several people already pointed out, that it would be nice, if we could
> > separate the data from the shell scripts and put the data into configuration
> > files. Soon after, I wrote dtxtdb along the ideas of Andreas' dcfgtool.
> > It's only purpose it to set and read back variables which were set by scripts.
> > (You could source [with sh(1)] the config files, if you want to, but dtxtdb
> > does some quoting and locking).
>
> again, for everybody:
> fact 1) many /etc/init.d/scripts contain some configuration variables
> (like OPTIONS= lines or out commented programs)
> fact 2) several developer started to move these informations out of the
> /etc/init.d/ scripts. so for 3 developers we haev 4 very
> different ways to do this.
> fact 3) we need to extract these config variables from the scripts.
> fact 4) if every developer uses it's own method to do this, we have chaos.
> fact 5) the easiest way is to have a /etc/config.d/file for each
> /etc/init.d/file and source these file to get the options.
> fact 6) using a small database like tool (dtxtdb) can give much more
> flexibility.
>
> we _don't_ want :
> - replace well known config files (/etc/hosts, /etc/smail*, /etc/uucp/*)
> - copy the information of well known config files into the database.
> - blow up the database with adding timestamps, history, help texts,
> lists of possibilities or whatever you want to see in the database
Again agreed.
I added my paragraph just for the completeness' sake to show the direction.
At the moment, I'm against the approach of parsing well-known configuration
files.
Do it step for step!
David
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: