Torsten Foertsch wrote:
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.
I don't think we're even talking about on-the-fly stuff for the "Lua"
parser engine, so Perl can do everything that Lua can. As people have
mentioned, though, Perl is bloated (but +1 for mp2.1 to include plugs
for this new config 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.
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.
I think if we take Paul's idea of a new pluggable API, we'll have a lot
of happy people. We can have a lua implementation, a perl
implementation, and IMHO we should retain some C implementation to the
crappy config that people (users) have now and are used to working with
(and bear in mind that there are STILL folks out there in 1.3-land
because of what we did to the httpd-2 config).
It would make everyone happy by having a C implementation that can be
used immediately without any new dependencies (and looks just like the
existing engine does), a Lua implementation which can come
out-of-the-box with mod_wombat (and we can even make that the "ASF
recommended" approach effective immediately as long as we keep
everything compatible at least until httpd-3 is ready), and mod_perl
(and friends) can provide other interfaces.
My EUR 0.02,
Issac
