httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Burry" <dbu...@tagnet.org>
Subject RE: Who decides what modules go in core release?
Date Thu, 22 May 2003 01:31:48 GMT
I already wrote a simple XML->XSLT->apache-config pre-generate thing
where I work...  It's not too complicated and pretty basic, the idea
goes like: 1) define what virtual hosts go on what machines, in what
clusters, environments, architectures, and what files if broken up into
multiple ones, etc... 2) Then the details of the config file(s): "in all
virtual host sections except X and Y do these apache directives, X and Y
do it this alternate way" and it includes a limited amount of variable
substitution too....  It was becoming too hard to maintain dozens of
mostly similar (but slightly different sometimes) configs otherwise....
Between development, staging, and production servers, for 15-20
international translated sites, hosted in various parts of the world, on
varying sizes of hardware and different architectures, with varying
versions of apache (some are 2.0 for the multithreading and cache
ability etc, some are 1.3 due to mod_perl and stuff like that).  It's
hard to make SURE that the right security settings are really set
everywhere unless you push those all out from one central system like
this...  It also makes it easier to extend it to a new machine or new
site, etc...  Note it's not a full converting of every Apache directive
to an XML tag name, that would be too hard for ME to maintain as Apache
evolves, I just needed better management ability only.  Apache
directives are still plain old normal apache directives, newline
separated, etc, just like always, so when someone says, "we need you to
take over maintaining X server for us, here's the config" it's not as
hard to just dump it into my system either...

In one respect it's much nicer than a real built-in macro language: you
can visually inspect its output in a very clean way before you post it
to a test server, perform some tests, and then the real server!  It's
sometimes very hard to visualize what a macro language is really doing
internally when you don't have that extra "generate" step...  It's also
not consuming additional memory at run time on the live server!

I know everything above could be maintained with IfDefines, but then
actually DOING the defines themselves have to be maintained in one
central system so you can keep them straight, and you still have this
huge glut of code pushed out everywhere instead of this simpler more
efficient config file that can be visually reviewed before pushing out
or if debugging anything (or just tweaked if experimenting)...

Anyway, there's always more than one way to skin a cat, to each his
own...  I'm not opposed to mod_macro but probably won't use it since I'm
using something else... Nice that I have that freedom no matter whether
it's included in the distro or not, thank god for modules! ;o)

Dave


-----Original Message-----
From: Marc M. Adkins [mailto:mmadki@Doorways.org] 
Sent: Wednesday, May 21, 2003 6:19 PM
To: dev@httpd.apache.org
Subject: RE: Who decides what modules go in core release?


> Anywho, you reminded me of a pretty significant shortcoming of our 
> defines processing... it would be good to be able to test <IfDefine > 
> of some more info from our build schema.  Some defines, E.g. WIN32, 
> HPUX11, etc could be very useful when choosing mutexing and other 
> things.

Mmmm, yes, that would be a big help.  OS symbols would be very useful.
Hostname and pathname of .htaccess files would have been useful in some
of my past installations (though I would solve all of these problems
with mod_macro now).

> Finally, some folks are looking forward to moving twords XML syntax 
> for the config (as an optional feature, folks!!!  Quit yowling!) While

> people have incessantly argued against macro processing for 
> traditional httpd.conf, it would be good to spell out, up front, a 
> macro syntax before we get to deploying such an XML parser flavor.

Well, if you have an XML syntax you should be able to use XSLT, which
should do the job nicely.  And is something like a standard.

mma


Mime
View raw message