Re: Who decides what modules go in core release?

[Joshua Slive <jo...@slive.ca>]

On Tue, 20 May 2003, Marc M. Adkins wrote:
> I feel like one or both of these modules should be part of the core release
> at some point.  The benefits are great, the code is written in at least one
> case, and there shouldn't be any conflict or breaking of other features.

Back when Dean Gaudet was around these parts, he used to shoot down
proposals like these with some regularity.  The basic argument is that
httpd.conf is a configuration file, not a programming language.  If you
need a programming language to generate your config files, there are many
preprocessors built for that purpose (eg. m4).

Of course, without Dean around, you might be able to sneak this in anyway
;-)

Joshua.

RE: Who decides what modules go in core release?

[David Burry <db...@tagnet.org>]

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

RE: Who decides what modules go in core release?

["Marc M. Adkins" <mm...@Doorways.org>]

> 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

RE: Who decides what modules go in core release?

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

At 10:57 PM 5/20/2003, Marc M. Adkins wrote:
>> > I feel like one or both of these modules should be part of the
>> core release
>> > at some point.  The benefits are great, the code is written in
>> at least one
>> > case, and there shouldn't be any conflict or breaking of other features.
>>
>> Back when Dean Gaudet was around these parts, he used to shoot down
>> proposals like these with some regularity.  The basic argument is that
>> httpd.conf is a configuration file, not a programming language.  If you
>> need a programming language to generate your config files, there are many
>> preprocessors built for that purpose (eg. m4).
>
>While I respect the argument, I don't agree with it.  Apache configuration
>files can be fairly large and complicated.  Maintenance quickly becomes an
>issue.  Macro pre-processing outside of the invocation of Apache is
>certainly possible.  It's just an additional step, an additional tool, one
>more link in the maintenance chain.  I know, that's what I've been doing so
>far.

While I respect your comments, I'd argue that macro and preprocessors
introduce *additional* confusion, not less, for less experienced administrators.
Sort of an argument against such a facility by default.

>I'm certainly not going to give up using mod_macro.  It's just too _useful_.
>It would just be nice if it were part of the core release simply because
>that would make it standard, everyone would know it was there, it wouldn't
>be necessary to track it down (and hack on it to get it to compile, as I had
>to do).

Nobody expects users *not* to add in mod_macro, mod_defines, etc.
They are terribly useful for some shops.  Others would rather build their
fixed configs through pre-deployment magic.

It was kicked around a while ago to adopt a cpan-like system for recovering
the latest modules and dropping them in (apsx++ anyone?)  Your comments
illustrate the need to finally tangle with that headache.

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.

Finally, we are moving to a much more sophisticated tree model for
httpd-2.x.  Although we now create a config tree, we actually throw away
very useful information when reading it, because we have two passes,
EXEC_ON_READ or simply loaded into the tree and processed normally.

This needs to become a three pass, read into the tree (*everything*), then
perform the process immediate bits, and finally run the normal pass.  There
are still EXEC_ON_READ handlers for special cases like mod_perl script,
etc, but we shouldn't be loosing our in-memory image of the config.

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.

Bill

RE: Who decides what modules go in core release?

["Marc M. Adkins" <mm...@Doorways.org>]

> > I feel like one or both of these modules should be part of the
> core release
> > at some point.  The benefits are great, the code is written in
> at least one
> > case, and there shouldn't be any conflict or breaking of other features.
>
> Back when Dean Gaudet was around these parts, he used to shoot down
> proposals like these with some regularity.  The basic argument is that
> httpd.conf is a configuration file, not a programming language.  If you
> need a programming language to generate your config files, there are many
> preprocessors built for that purpose (eg. m4).

While I respect the argument, I don't agree with it.  Apache configuration
files can be fairly large and complicated.  Maintenance quickly becomes an
issue.  Macro pre-processing outside of the invocation of Apache is
certainly possible.  It's just an additional step, an additional tool, one
more link in the maintenance chain.  I know, that's what I've been doing so
far.

I'm certainly not going to give up using mod_macro.  It's just too _useful_.
It would just be nice if it were part of the core release simply because
that would make it standard, everyone would know it was there, it wouldn't
be necessary to track it down (and hack on it to get it to compile, as I had
to do).

mma