Re: Consesus on Linuxconf?
Raul Miller <rdm@test.legislate.com> writes:
> Andreas Degert <ad@papyrus.hamburg.com> wrote:
> > please don't answer too quickly; if you think about it a second
> > (in the context of the thread) you will realize that I wrote about
> > syntactically and semantically correct config files that are too
> > complex for the parser.
>
> That shouldn't matter for context free grammars. If the grammar
> isn't context free you're dealing with something like unrestricted
> perl, not a config file.
That is not the point; of course just the parsing, the syntactical
portion, is rather easy. Else, how should a program like samba parse
it's config files? Even if it's a complex embedded language, by
definition its syntax can be parsed, and if it's for a program you
even have the source for it. The problem lies in understanding the
semantics from the users point of view, so that it can be presented to
the user in a reasonable form. This is what the parser of a
configuration program has to achieve.
> > For, samba, a config file overwriting some global setting indirectly
> > with the line
> >
> > include = /etc/smb.conf.%m
> >
> > occurring later in the config file (%m expands into the client machine
> > name) is already tough for the parser (and the ui displaying the
> > data).
>
> You mean a non-global override of a global default?
It's both in the global section of the config file; you can use it to
set a default log level for all clients, but a different log level for
specific clients (just one example). It's "local" with respect to a
single client; just can also use %a instead of %m, which will expand
to the architecture of the client machine, or %R for the protocol
level client and server have agreed upon.
>
> For a UI you need an area for defaults, and you need to be able to
> enter specifics (specific file system areas, specific printers). Under
> a specific file system entry you need to be able to represent the
> defaults and you need to be able to represent overriding them.
You can special-case it for my example, and I'll just make my example
a bit different or more complex. For example, as the user gets fed up
with different log level for his 1001 clients, he just puts a
log level = 1
_after_ the line with the include statement. Perfectly valid. Samba
will run with log level 1 for all clients, though other
client-specific settings will be retained. And the nice thing, when
the user comments out this additional line, he has the old
client-specific log-levels again. How do you make a config program
understand that and present it to the user? One goal was that no info
shall be lost, so it would be illegal if the config program zapped the
config lines that are globally overridden. If you modify a
configuration that was read from a definition which is spread over
several files, into which file do you put the new/changed
configuration statement?
IMHO, if you want to handle all these cases, the configuration program
gets more and more complex, also for the user, and in the end it's
worse than just giving the user an editor and a manpage. A
configuration program should guide the user through the configuration,
and prevent him from defining silly configurations, even if they are
formally correct. You have to draw a line somewhere, and this means
your configuration program will have to reject reading some config
files that are perfectly valid and meaningful for the special case of
some user. OTOH, you will prevent a lot of users from screwing up
their configuration.
I took the example of samba config files, because at the first look
they seem to be very simple (it's the windows ini-file syntax, with
sections and assignments to keywords). But the simple existence of
these include statements makes it much more involved. I haven't found
a configuration program which handles samba includes well.
If you look at config files like .emacs or /etc/profile where it's
apparent that they use a structured language, it's much more clear
that a configuration program can't grok each possible config file the
user can write with an editor.
ciao
Andreas
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: