httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Schaefer <>
Subject Re: [multi-env] perl glue status
Date Sun, 10 Apr 2005 13:55:09 GMT
Markus Wichitill <> writes:

> Randy Kobes wrote:
>> Perhaps apreq2 could provide a ::compat module, in the
>> spirit of mod_perl-2's Apache2::compat, to provide
>> a compatibility layer?
> I think it's more of a perlishness issue than a compatibility
> issue. Perl users don't want to deal with C API implementation
> details. They just want to get an upload object without doing the
> $body->param_class() voodoo. Move the upload object accessor
> method to the APR::Request namespace, that's fine, but please 
> don't make things more complicated.

Agreed.  If we dropped Apache2::Request, we'd certainly
move upload() into APR::Request.

>>> I doubt that any of my users will ever have such a setup,
>>> so I'll have to continue support for plain mp1+apreq1.
>> It's been mentioned a couple of times on the mod_perl-2 list
>> that, down the road, it might be an idea to split the APR::*
>> modules out from mp2, as they in principle work
>> independently of mp2.
> That would be nice, but doesn't help in my situation where people are
> stuck with RedHat 7 etc. and their bundled Apache1/mod_perl/apreq
> versions. If I ignore them, the number of people using my open-source
> stuff under plain CGI will increase from 90% to 99%, with more people
> defecting to PHP. 

Bingo.  The problem we have with apreq2's perl glue is that all
our prior planning was predicated on CPAN supporting generations,
so we wouldn't hurt our apreq1 user community with an official
apreq2 release.  We need a new plan now, but I'm not sure yet what 
the right approach is yet.

In the meantime, I'll just keep chugging along on the C APIs.
The major issue right now is basic charset support, and acquiring
a good set of tests for that.

Joe Schaefer

View raw message