Re: Admin tools - idea from left field
On Thu, February 11 1999, Chris Waters <xtifr@dsp.net> wrote:
|Amos Shapira wrote:
|> True (about "Don't go down that road"). But is procedural programming
|> THAT crucial?
|
|If you want something that can (in theory) be used for *all*
|configuration, then yes, procedural programming *is* that crucial. 90%
|or even 99% is NOT good enough.
I'm just trying to envision how am I going to use a system based on
such configuration files, based on my experience so far in managing
UNIX and Linux systems:
1. Many config files are parsed "on the fly" many times a day when a
program is invoked, they therefore usually have to be fast to
parse.
2. Config files tend to be pretty simple and easy to parse since they
should be easy to understand by non-programmers as well as easy for
programmers to follow and modify.
3. Even config files which allow scripting (e.g. shell script files)
almost never take advantage of the scripting capability mainly to
keep them easy to follow and modify.
|The FSF was, last I heard, planning to use Guile in this role. Guile
|may not be ready for the job *yet*, but unlike XML or tcl, it should be
|powerful and flexible enough. There was a long discussion on the GNU
|mailing lists about Guile vs. tcl, so lets not rehash that here.
OK, I don't feel a special urge to get into a language comparision
discussion :). But still I DO think that a static config file would
be easier to use and manipulate than an interpreted language.
For instance, I'm playing with a Python RADIUS module now, the author
did the obvious thing and put the configuration in simple Python
scripts which set variables (by calling some application-specific
functions). I can probably take advantage of Python and start calling
those functions in loops and such, but I can manage without it and
keep the file simpler. Complex configuration files tend to be much
less friendly to administrators.
In addition:
1. Using some "static" format should enable a transition from the current
"proprietary" formats by providing a "back-translator" so you can keep
the parsing out of the applications for now. How would you do this with
an interpreted config file?
2. If/when you decide to move to a scripted file, you can keep the
old/transitional static format when you move to a scripting
language by supplying a function to read the old-style format while
"running" the new configuration script. If you don't standardise
on a common static format then you'll have to implement (or tweak)
every interpreter of every application you are going to change.
3. By choosing a scripting language you'll force your users to have to
learn programming and have to learn THAT language. It won't be a
hurdle for me personally, but it might yet again make your system
less user friendly to "joe-linux-user" who wants to just get the
work done.
4. How would you provide nice GUI tools to manipulate scripted config
files?
What I'm generally arguing is that even if you decide to go the path
of scripting, you'll end up with something which reads simple static
files most of the time, for the sake of the user's sanity :).
|The FSF considered tcl and rejected it, and they're doing a lot more
...
|If there are problems with the way Guile works *now*, the appropriate
It looks like you are focusing about Guile vs. TCL vs. anything. I
don't. I'm focusing on a point above that. I think our purpose (of
making Debian (and Linux in general) systems easier to use and manage)
would be much better served by static files.
I've raised some of those points in my previous message but haven't
seen any reaction about them. Maybe I can try to point them more
clearly?
Cheers,
--Amos
--Amos Shapira | "Of course Australia was marked for
133 Shlomo Ben-Yosef st. | glory, for its people had been chosen
Jerusalem 93 805 | by the finest judges in England."
ISRAEL amos@gezernet.co.il | -- Anonymous
Reply to: