httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fabien COELHO <>
Subject Re: FW: general/3563: I want to allow the definition and use of macros within runtime configuration files.
Date Thu, 24 Dec 1998 09:49:09 GMT

Dear Dean,

> > > *Apache's configuration language is a piece of crap to begin with.  
> > > It is inconsistent, and non-obvious. I've never claimed otherwise.*
> > 
> > Sure. So don't try to improve it:-( 
> Again, you're way off.  I want it improved.  I want it improved
> desperately, beccause I think it's a load of crap.  I don't want it
> improved bit by bit.  I want someone to sit back and design something
> that makes sense, and implement that.  If you look in the archives, search
> for XML.  You'll find previous discussions on this topic, and you'll see
> that many of us think that XML is a suitable replacement language.  And I
> do believe it satisfies your macro needs, but then I'm not sure, because
> I don't do XML.  If it doesn't, then perhaps you should participate in
> the definition of a new language.

XML == eXtended Markup Language. It is intended to document structuration.


However it is NOT intended to human beings, but to "XML processors".
It is written in the specs.

I hope nobody will ever have to write actual XML by hand.
Especially if the problem at hand to to configure an http server;-)

I don't think that the current status of the "apache language" is
compatible with XML. XML is case-sensitive. The use of sections in apache
does not match ther syntax (should have <THIS NAME=VALUE NAME2=...>).
Character and lexical assumptions are not compatible with apache lazy
keyword delegated per-line parsing. XML is verbose. Defining macros
(ENTITY) with XML is quite verbose and uggly. 

I don't think that switching to XML would be a good move, if the
configuration files are to be written by "someone" (but it is ok for

I'm not "something";-) I do think that simple textfile-based configuration
is a feature to preserve, next to possible GUI oriented configurations. 
Administrators don't necessarily like perl, but they like vi or emacs. 

I will participate to the definition of a new language, no problem!
Especially I don't think than one is actually needed, because ascendent
compatibility is an important issue. Also there *is* an apache conf style.
What is needed is some little fixes and guide lines to the addition of new
configuration keywords. Maybe an emacs-mode could also help.

I'll defend this opinion. I'll also look at the XML past discussions.

> > Just let people deal with the 'crap' and wait for the vision, the great
> > abstraction that is announced, Brother. Thou can believe it, the Lord
> > shall come some final day and solve all your problems. Just wait for it or
> > do some perl-or-anything programming till then;-).
> No, if I don't veto this, then you and everyone else will continue
> this hodge podge approach, and nobody will begin working on 2.0.

"hodge podge" is not in my English dictionnary, but "hopus pocus" is. 
I assume this is negative anyway;-)

You may also consider what is apache to its end-users. The way they see it.
The interface is:

 - several web sites (* that are great.

 - an automatic configuration, easy additions of modules (?), installation
   that are great but may be improved (have you ever try to type 
   several --add-module=this --... on several lines? maybe a perl-like
   front-end to configure could help?)

 - HTML documentation, FAQ, ... 
   which are all great and helps a lot.

 - configurations files that must be written to make the stuff work...
   they can be improved. I have suggestions. I don't think that
   any revolution is needed.

 - tools for statistics, logging management, testing...
   (analog, rotatelogs, chronologs, ...)
   that are great but could be improved further for some of them.

 - overall performance, reliability, maintenance...

This define area of improvements to end-users. They don't really care
about threads or processes, or whatever. The what and how to get it and
how to manage it is important. The how it is done is your concern as a
developer. Also the direction of evolution, obviously, is your concern. 
I come with my suggestions... and it is discussed. Great;-)

Thanks for the discussion. Have a nice day.


View raw message