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?
