Config parsing (1/4): General principles

Russ Allbery rra at stanford.edu
Thu May 10 17:20:50 UTC 2001


Forrest J Cavalier <mibsoft at epix.net> writes:

>>     This principle is intended to outlaw the proliferation of parsers;
>>     INN should have a single configuration parser that everything
>>     uses. It's also intended to outlaw syntactic differences between
>>     different configuration files.

> I think that is unnecessarily restrictive.

> The rest of the philosophy and general principles are great, and some
> points were discussed here some time ago.

> I say stick the API in, but then don't "outlaw syntactic differences".
> Then Fabien can provide interfaces to use his configuration stuff.
> Other sites would be able to bolt database back-ends onto INN.

Okay, I've toned this down to:

 2.  Adding a new configuration file or a new set of configuration options
     should not require writing a single line of code for syntax parsing.
     Code that analyzes the semantics of the configuration will of course
     be necessary, but absolutely no additional code to read files, parse
     files, build configuration trees, or the like should be required.
     Ideally, INN should have a single configuration parser that
     everything uses.

> If the code gets modified to go through the API, then why do you care
> that it comes from a configuration file with an outlawed syntax?

Well, I'm trying to solve two problems.  One of them is the proliferation
of different internal ways of getting configuration information, and going
through a single API will definitely fix that problem.  But the other one
is that users end up having to understand more than one syntax in order to
configure INN, which I think is a large part of what makes INN
configuration so hard to understand.

If the proposed configuration syntax is deficient for whatever reason,
then I think we should try to fix it and improve its expressiveness rather
than add an additional separate syntax.  Since everything goes through the
API, we should be able to make changes like that much more easily than we
can now.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>


More information about the inn-workers mailing list