httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Issac Goldstand <mar...@beamartyr.net>
Subject Re: Dynamic configuration for the hackathon?
Date Tue, 01 Apr 2008 09:35:15 GMT



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

Mime
View raw message