httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Randy Kobes <>
Subject Re: [RT] what's the roadmap?
Date Tue, 21 Feb 2006 17:34:32 GMT
On Tue, 21 Feb 2006, Geoffrey Young wrote:

>>> in principle I don't mind this idea, and we can 
>>> certainly consider taking the perl glue under the 
>>> mod_perl project.  I guess the more difficult part would 
>>> be in deciding how to package things so that it's the 
>>> least complex for the end user.
>> From the experiences I have had talking to people on the 
>> mod_perl list about mod_perl2, the most common issue for 
>> users coming from mod_perl 1 is how to handle the request 
>> data other than using $r->args or CGI.  I think that 
>> having the perl glue install alongside the standard 
>> mod_perl libraries would be ideal.
>> IMHO, a sizable chunk of mod_perl first timers are 
>> looking to process arguments from a form, which can of 
>> course be done with CGI but having native libraries to 
>> handle this would be a big win.  Make the perl glue libs 
>> readily available to the user with a standard mod_perl 
>> install.
> I think that may be more difficult than it sound at first 
> - currently, neither version of mod_perl depends on 
> anything outside of core httpd for its API to function, so 
> if apreq weren't part of httpd core it might be more 
> complex.
> but I think discussions like this are secondary and belong 
> as part of the normal development chatter.  the real issue 
> here is whether the parts of apreq are better served by 
> two distinct communities - httpd for the base C module and 
> mod_perl for the perl glue.  and the more I think about it 
> the more this really makes sense and would be very healthy 
> for the project, communities, and users alike.

There does seem to be consensus for this split for the C 
side to go into httpd. Is there some fundamental objection 
from somewhere opposing this? At one point in the past it 
was suggested, as an argument to get apreq into the core 
httpd, to have mod_autoindex use apreq to parse the query 
string; would it be useful to demonstrate this to push for 
apreq's inclusion?

On the Perl side, one thing that we may wish to consider is 
splitting the APR::* modules that just rely on the apr libs 
from mod_perl into their own distribution. As well as making 
these modules potentially more useful in a wider context, 
this would also allow the perl glue of apreq to be built for 
use just in a cgi environment, without the need for a full 
mod_perl installation.

best regards,

View raw message