On Tue 01 Apr 2008, Paul Querna wrote:
> William A. Rowe, Jr. wrote:
> > -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.
I disagree. In the mod_perl API you can almost entirely configure a single
request. You can hook maptostorage and add there directives for other modules
via $r->add_config. Anything that can be configured in .htaccess or
<Location> can be done that way as well. One can even change DocumentRoot
(prefork-only) for a single request. The PerlMapToStorageHandler can then
decide whether to skip the standard maptostorage (directory walk and file
walk) or not. It would be good for such a perl-configured request to be able
to skip the location-walk that follows maptostorage. But if the admin wants
to do that he can simply avoid <location> blocks.
You cannot add virtual servers on the fly or redirect error_log. But I don't
expect that to become feasible in the new config language since those are
things that are done at server startup.
> 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.
I agree that a configuration language like lua is good but it doesn't
necessarily have to be in core. It can be a module as mod_perl shows.
Torsten
