Paul Querna wrote:
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.
Not completely true. mod_perl provides several ways to bind to the
configuration. Consider this bit of Perl magic - this is some mp1 code,
running in Perl-land, not in a <Perl> block, though it could as easily
be run there...
package Apache::ReadConfig;
no strict;
$Location{$UploadScript} = {
Options => '+ExecCGI',
PerlHeaderParserHandler => $namespace."::upload_jit_handler",
};
$Location{$UploadMeter} = {
Options => '+ExecCGI',
PerlHeaderParserHandler => $namespace."::meter_jit_handler",
};
$Location{$UploadForm} = {
Options => '+ExecCGI',
PerlHeaderParserHandler => $namespace."::form_jit_handler",
};
Granted, you're still limited to the underlying config parser, so I'm
not arguing with the new config API idea (at least as I understood it
yesterday), but this should be treated as a pluggable config engine
which everyone can access; not as a switch from one config parser to
another.
Issac
