httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <dgau...@arctic.org>
Subject Re: what Apache configuration file should/could be
Date Mon, 01 Mar 1999 15:52:24 GMT
another old message...

On Mon, 28 Dec 1998, Fabien COELHO wrote:

> Here is a little analysis of the current status of apache configuration
> stuff,  and the area for improvements I can see. And suggestions. This is
> a contribution to the great thinking about version 2, but I think that
> 1.3.5 would be a reasonnable release target... Here I'm focussing on the
> what from the user point of view, not on the how from the developper point
> of view. 

We'd never introduce a major configuration language change in a minor rev. 

> I REQUIREMENTS (What is needed to configure a software such as APACHE)
> 
>  1 CONFIGURABILITY (anything that could be configured must be configurable)
>  . no arbitrary inforced defaults (as 3 configuration files...)

Yup.

>  . csq: many settings and options, thus many keywords...
>     => apache configuration WILL BE VERBOSE

What do you mean by verbose?

>     => some general utils could help in this area...
> 
>  2 MODULARITY (apache is an open software!)
>  . easy addition of new modules and their configuration.
>    (ok with textual confs, but what about GUI?)

GUIs can talk the text config language.  We're never getting rid of the
text language. 

>  . csq: - need loose constraints (char/lex/syntax)
>         - delagated parsing (to enable extensions such as perl sections...)

Yeah this is something I've babbled about.  XML gives us this, no?  We can
do arbitrary "quoting" of sections and delegate who parses them... 

>  . status: ok 
>         - raw text configuration files.
>         - backslash-continued keyword-controlled lines
>         - html-like nested sections
> 
>  3 SIMPLE (easy expression of HTTP concepts)
>  . integrated concepts such as VirtualHost, Directory, Location, Limit...
>  . no escaping, direct expressions, usual conventions
>    [e.g. <VIRTUALHOST NAME="this" PORT="80"> -> <VirtualHost this:80>]

I'm not particularly attached to any of the current syntax.  It does
absolutely nothing for me.  It pretends to look like HTML, but last I
looked at HTML, something like <virtualhost foo>blah</virtualhost> is
valid, but not in apache's language.  I consider the "one command per
line"  crap to be crap.

>  4 USER-FRIENDLY (some*ONE* is to configure apache)
>  . textual conf ok to administrators (vi/emacs), web/gui for others...
>    diversity is great!
>  . the more homogeneous the better

Yes, this is the most important point.

>  . the looser the better (?, for instance, case-insensitive keywords).
>  . nice error messages help (location, explanations, tips...)
> 
> 
> II CRITERIONS (to evaluate "improvements";-)
>  1 compatible?
>  2 simple
>  3 homegenous
>  4 modular
>  5 user-friendly
> 
> 
> III SUGGESTIONS
>  1 publish guidelines for extensions (for simplicity, homogeneity...)
>  2 provide general utils at the core level.
>  3 make apache core features meet these guidelines.
>  4 but provide backward compatibility (with warnings) if changes are necessary.
> 
> 
> IV PROPOSED GUIDELINES 
>  (they already +- exists. it's a recommended good practice)
>  1  make everything configurable [so drop hard-wired 3-files stuff]
>  2  use capitalized keywords [update "order deny require allow ..."]
>  3  use html-like simple nested sections.
>  4  make case insensitive what can be.
>  5  use simple names/phrases for options ["deny,allow" -> "DenyThenAllow"]

Yup, we should lose the NCSA compatibility and go for something sane. 
Someone can write a perl script to translate NCSA/old-apache configs to
new configs. 

>  6  use default lexing (char * ap_get_keyword(...))
>  7  avoid junk 
>     [ "allow blabla ..." -> "AllowFrom". "<Limit ...> skipped junk here" ]
>  8  avoid implicit default options...
>  9  please detect inconsistencies (e.g. if "order" is specified twice, say it!)
>  10 try to prefix keywords per module (SSL*, AuthDBM*...)
>  11 a path can be relative to ServerRoot
>  12 use "!" if you mean not, inverse...
>  13 use "On/Off" if you mean +/- Yes/No Enable/Disable True/False...
>  14 use standard file/string regular expressions...
>  ...
> 
> 
> VI UTILS (that may be useful)
>  1  working Include
>  2  some conditionnal stuff <If??? ...>, <Else>???
>  3  user-controlled Error/Warning
>  4  macros (to help solve verbosity issues)
> 
>  and maybe (I don't claim it must be)
> 
>  5  repetition (<Foreach $i ...>) (? 0)
>  6  minimum variables (Environment? useful? 0)
> 
> 
> V ACTIONS
>  1 drop hard-wired 3 files stuff
>    [compatibility: add a "apache.conf" file which is used by default,
>     and which contains Include etc/httpd.conf; Include etc/srm.conf; ...]
>  2 update apache core features [esp. deny allow order require ...]
>  3 decide what utils are needed;-)
>  4 improve internals/hooks and so (not user-visible changes)
> 


Mime
View raw message