httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <>
Subject Configuration Issues to Address [was Re: Dynamic configuration for the hackathon?]
Date Wed, 02 Apr 2008 21:50:30 GMT
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?

View raw message