Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <47F3FFA6.8090904@rowe-clan.net>
Date: Wed, 02 Apr 2008 16:50:30 -0500
From: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
User-Agent: Thunderbird 2.0.0.12 (X11/20080226)
MIME-Version: 1.0
To: dev@httpd.apache.org
Subject: Configuration Issues to Address [was Re: Dynamic configuration for
 the hackathon?]
References: <C417A5C6.AD05D%Brian.Akins@turner.com>
In-Reply-To: <C417A5C6.AD05D%Brian.Akins@turner.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Akins, Brian wrote:
> 
> The biggest problems I have with current system are:
> -Every module does things differently

Within limits this will remain true.  But we are missing a host of very
trivial simplifications for the casual module developer, and reinvent the
same wheel module after module.

I'm going to propose some changes to the default TAKE[0-9]+ macro and
support functions to illustrate how much more useful these can be, and
offer some new functions that make it really simple to

   * define constraints (an int, sure, but in what range?)
   * tag default-value, and error out if a non-default value is replaced
     by the user (e.g. LogLevel debug ........ LogLevel error later on)

> -No real per-request configuration.  Some modules use env to do some of
> this.

ixnay on the run-time intensive, slow down the server sorts of changes.
httpd continues to become slower as it becomes more powerful.  I know you
are the first one to raise your hand and point out when we are doing too
much processing for too simple a request.  Isn't this what modules are for?

Perhaps you could elaborate?

> -I have to write a good bit of code before a module is configurable. (I'm
> lazy. Very lazy.)

Agreed - see my first point.

One interesting point; why do we keep per-server and per-dir sections?
Perhaps it's time for a single simpler-to-use mechanic which can represent
either or both (essentially deprecate per-server in 3.0).

> If we do what niq suggests (which, if we stick with current config system is
> fine) is that it just adds another layer on top of all the existing issues.
> 
> With lua, for example you could make modules Lua modules... Maybe could do
> same in perl?? 

That's why I'm not a fan of all lua all the time.  But to do what we all
want, I bet we'll need to refine the config API, and simplify it for adding
pluggable semantic engines (lua, perl, simply 'sed' etc).

> My opinion (which is worthless, I know) is to pick one way and do it.  Lua
> is easy to learn and satisfies most (all?) of our requirements.  And if
> Brian M. and I can learn it, anyone can ;)

Most importantly, if I am building an embedded httpd, I don't want all of
this extra crap.  httpd was famous for how lean it could be, are we all
ready to throw out that advantage?