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 Tue, 22 Dec 1998 19:26:24 GMT

> > 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.
Maybe my English skills can be improved:-(

> > 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.

What bother me is that for a simple problem (copy-paste) with a simple
solution (macros), the suggested 'right' solution is "do some
programming", esp with perl (or python or m4 or whatever). 

That's a bazooka to kill a fly. It's perfect to bazooka-addicts.

> > 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#.

You can do that with a macro, if you add a parameter for foo instead of
putting a constant. It's already in;-)

>  Then the day after
> that someone else will want a way to iterate over a set of tokens.

Well, if it is really useful (reduce file size and improve readability, my
little criterions, not for Church-completeness) I would consider it

> 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.

So what. 

There are already books about APACHE configuration at O'Reilley, not
necessarily for dummies. That would be a place for documenting it. If they
can explain mod_rewrite to dummies, they can also explain a simple macro
definition, it's a lot easier, believe me;-)

> It's pretty clear that you don't understand perl.

I do undestand perl programming. I was arguing that people don't need to
think your way to solve their problems, they can prefer other solutions
and even other mecanisms, such as integrated macros for instance.

> The entire thing can be solved in one file.
> There's no need to split it up as you insist.

Well, if you want all your configuration to be generated by perl.  But
let's say I just want to generate some parts only, here and there, I do
not want to turn to perl for my whole conf file(s) which work
perfectly. That too large a pace for the small problem at hand.

There is no way for me to solve my maintenance problems by switching a
raw apache conf file to a perl-or-whatever script. 

> Maybe it's my world view that's skewed... 

Everyone view of the world is particular. Very hard to understand other
people's problems.

> 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.

No. I don't want to program, because if one switch from a raw
configuration file to a piece of m4/perl/python programming, it is
not going to improve maintenance. 

> > 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.*

Sure. So don't try to improve it:-( 

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;-).


View raw message