Date: Tue, 22 Dec 1998 10:21:09 -0800 (PST)
From: Dean Gaudet <dgaudet@arctic.org>
To: new-httpd@apache.org
Subject: Re: FW: general/3563: I want to allow the definition and use of
 macros within runtime configuration files.
In-Reply-To: <199812220827.JAA22224@blonville.caii>
Message-ID: <Pine.LNX.3.96dg4.981222100458.22458C-100000@twinlark.arctic.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: new-httpd-owner@apache.org
Precedence: bulk
Reply-To: new-httpd@apache.org


On Tue, 22 Dec 1998, Fabien COELHO wrote:

> my point was just to show that m4 is not really appropriate for the
> purpose, which does not mean it is impossible to use it.

Then you failed to show your point.

> How nice to have to write a perl script. That's user-friendly;-)

I don't know which web you work with, but every admin I know who works
with the web I'm familiar with knows perl.  It's pretty damn ubiquitous.
And consider your alternative -- defining a new language... for which
there are no "dummies" books or O'Reilley books, or FAQs... or...
perl has a huge infrastructure of support set up for it already.

And if perl bothers you, replace it with python.  Or any other language
of your choice.  That's my point:  there are dozens of languages which
suit this job already, we should not invent another.

> If I want to "program" for my configuration file, sure I could do that.

Sure, today all you want is simple text replacement within a macro.
Then tomorrow someone else will want s#foo#bar#.  Then the day after
that someone else will want a way to iterate over a set of tokens.
Then the day after that... and suddenly we'll have a language which has
been cobbled together, and is full if incosistencies, and is in no way
"user-friendly".  Yeah, this is how perl came to life, but as I mentioned,
perl has a huge advantage already: lots of folks know how to use it.
The only people who "win" from us inventing another such language are
the folks who will have to write "dummies" books to insturct others in
its use.

> But this does not improve at all the readibility of my configuration files
> (you have the path to the script in your file. boo). Moreover this can be

The relative path.  Your point is what?  If that bothers you, then use
the -C command line option, and wrap the httpd executable.

> a lot for small configuration macros. The contents are moved to the
> scripts (in perl or whatever) and I have to write a new file for any small
> "macro" I would need, or not to write any. The configuration is broken
> into pieces in many files. It will require more lines and more skills
> (mastering perl) from me (and the many apache administrators) than an
> integrated solution.

It's pretty clear that you don't understand perl.  The entire thing can
be solved in one file.  There's no need to split it up as you insist.

Maybe it's my world view that's skewed... but if you're an admin that
needs this sort of functionality, you probably already know how to program
in perl.  If you're an admin with a tiny site, you have no need for this
functionality... you don't need to program in perl.

> 		Basically, it does not solve my problem.

That's fine.  Then you don't have to use perl.  Use whatever
you want, the mechanism is general.

> Moreover "Include" includes limitations, that I would name bugs. I know
> about them because I first implemented the macro module the way Include
> is implemented and it just couldn't work, I had to change my implementation.

Yes, and see my above point about growing a language bit by bit.
This sort of thing is exactly what I expect from such hodge-podge
approaches to language design.  *Apache's configuration language is
a piece of crap to begin with.  It is inconsistent, and non-obvious.
I've never claimed otherwise.*

Dean