perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <>
Subject Re: [mp2] Making Apache::ASP optimized for mod_perl 2
Date Wed, 07 May 2003 01:39:06 GMT
Josh Chamas wrote:
> Stas Bekman wrote:
>>>> So an Apache::Common, might just be:
>>>> package Apache::Common;
>>> I would suggest that Apache::Common be only the things we used to 
>>> have in mp1 - for example, people are used to having $r->print and 
>>> $r->server but $r->pool is new.  even though we need pools for 
>>> cleanups, I think _not_ hiding it will help people migrate as well.
>> As I've explained in my reply to Josh, Apache::Common won't work, as 
>> everybody has a different requirement from mp2. However if you want to 
>> provide a list of modules to load to make it work as in mp1, I think 
>> this is possible but the name should reflect that. For example 
>> Apache::LoadMP1Modules or something like that.
> How about some importer that was function based, say...
> use Apache::Loader qw(:common log_error :default you_name_it )
> :common might load the LoadMP1Modules for example, or this might
> just be :mp1 ... it might just be a ModPerl::Method helper ...
>   use ModPerl::Method qw(:mp1)
> or something like that?

I like this.

again I don't think it's going to be easy to define what should be in 
':common'. However it's quite easy to do:

use Apache::Loader qw(:request :server :mp1);

individual methods can be passed, and they will be automatically looked up 
using ModPerl::MethodLookup. So we only need to hardcoded the module lists for 
:request :server :mp1 and keep them in sync if new modules are added.

>> No matter what conveniece helpers we provide, I'd still strongly 
>> suggest to CPAN authors not to use any of the helpers. Since in most 
>> cases you don't need all the MP1 functionality for your specific CPAN 
>> module, keep the list to a minimum.
> Right.  The keyword loader as above might be nice to have people specify
> groups they are interested in loading like the :mp1 group assuming they
> flexed most of that API.

May be in the spirit of ModPerl::MethodLookup, we call it ModPerl::MethodLoad? 
Internally it'll use ModPerl::MethodLookup.

Also I'm thinking about adding a special module called 
ModPerl::ProductionTest, what it'll do is:

$INC{'Apache/'} = __FILE__;
$INC{'ModPerl/'} = __FILE__;

so when anything tries to load Apache::compat or ModPerl::MethodLoad it'll be 
a no-op. The result is that you can test your code whether it'll work on other 
users machines when they get it from CPAN. The problem I'm trying to solve is 
you might be unaware that some module that you use loads Apache::compat and 
therefore you code works while it won't work on other setups without that bad 
module which have loaded Apache::compat, even though they were asked not to.

Does it make sense? This is a sanity check tool for CPAN developers.

Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker     mod_perl Guide --->

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message