William A. Rowe, Jr. wrote:
Issac Goldstand wrote:
Paul Querna wrote:
Akins, Brian wrote:
On 3/26/08 9:06 AM, "Nick Kew" <[EMAIL PROTECTED]> wrote:
There seems to be a demand for dynamic per-request configuration,
as evidenced by the number of users hacking it with mod_rewrite,
and the other very limited tools available. Modern mod_rewrite
usage commonly looks like programming, but it's not designed as
a programming language. Result: confused and frustrated users.
This is what I had in mind when I suggested having <Lua> blocks of
code. No
need to invent a new language when a perfectly fine one exists...
+1, and embed Lua in the core, and a dozen problems just like this
are solved.
-0.5 PLEASE not in the core. Make mod_wombat a standard module and
part of the default moduleset, whatever, but let's not make more core
dependencies, please?!?
-0.99 - agreed. Perl is perfectly happy having <perl> blocks as modular
behaviors... I've noticed a trend in the last few years of building on the
core (and folks rightfully accused me of growing mod_proxy core when new
directives are rightfully part of mod_proxy_{whatever}).
Yes, but the root of the problem even with <perl> blocks is that they
have almost no way to change the behavior of existing modules -- like
you can via configuration -- and instead for the most part, they
reimplment entire C modules in Perl, or any other language, rather than
binding to the configuration, and change that based on some other inputs.
The few that can change behaviors, ie via ENV vars, are special cases in
every modules case, and do not make a difference in the larger picture.
The core of what I want is a better configuration API.
Then the existing configuration file, a new lua system, or anything
else, could be written in terms of that, rather than the current system
where each language reinvents the modules it wants to control.
-Paul
