You are viewing a plain text version of this content. The canonical link for it is here.
Posted to apreq-dev@httpd.apache.org by Joe Schaefer <jo...@sunstarsys.com> on 2005/04/08 07:49:30 UTC
Re: [multi-env] perl glue status
Joe Schaefer <jo...@sunstarsys.com> writes:
> Time to review, stabilize & document the perl glue.
> The major change is the Apache:: -> Apache2:: rename.
Instead of renaming, let's just toss Apache::Request and
Apache::Cookie. At the moment they're just stupid perl
modules wrapping APR::Request::Apache2 and APR::Request::Cookie.
I think we're better off developing the APR::Request
namespace instead of just renaming the old Apache:: APIs to Apache2::.
Thoughts?
--
Joe Schaefer
Re: [multi-env] perl glue status
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Fri, 8 Apr 2005, Joe Schaefer wrote:
> Joe Schaefer <jo...@sunstarsys.com> writes:
>
> > Time to review, stabilize & document the perl glue.
> > The major change is the Apache:: -> Apache2:: rename.
>
> Instead of renaming, let's just toss Apache::Request and
> Apache::Cookie. At the moment they're just stupid perl
> modules wrapping APR::Request::Apache2 and APR::Request::Cookie.
> I think we're better off developing the APR::Request
> namespace instead of just renaming the old Apache:: APIs to Apache2::.
>
> Thoughts?
I agree ... With the mp2 shift to Apache2::, one will have
to do some (hopefully straightforward) renaming anyway, so
now seems like a good time to migrate fully to APR::.
--
best regards,
randy
Re: [multi-env] perl glue status
Posted by "Edward J. Sabol" <sa...@alderaan.gsfc.nasa.gov>.
> If that's the case, I'd rather keep the wrapper classes.
I definitely agree! You'll break a lot of existing code otherwise. Even if
the changes are "straightforward," that's *not* a good thing.
Re: [multi-env] perl glue status
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Markus Wichitill <ma...@gmx.de> writes:
> I'm less concerned about the conditional code, which is
> needed in lots of other places anyway, but more about the
> apreq2 API. That $body->param_class('APR::Request::Param')
> business just isn't very elegant, if it's indeed meant to be
> the final API for this purpose.
It probably is, because that's a better reflection of how the
C API is designed (and the only alternatives I could think of
involve overloading "", which is a massive performance hit).
I don't mind providing Apache2::Request etc, but what concerns
me about that is: what should we do with $req->args? IMO
$req->args must be Apache2::RequestRec::args iff $req isa
Apache2::RequestRec, but it must be APR::Request::args iff
$req isa APR::Request::Apache2. So if somebody that's already
using apreq2's Apache::Request thinks they can just s/Apache/Apache2/g,
they're going to be in for a shock if they don't correct args()
also.
--
Joe Schaefer
Re: [multi-env] perl glue status
Posted by Michael Peters <mp...@plusthree.com>.
Joe Schaefer wrote:
> Michael Peters <mp...@plusthree.com> writes:
>
>
>>Joe Schaefer wrote:
>
>
> [...]
>
>
>>>How about something like this?
>>> use APR::Request::Apache2 compat => "apreq1";
>>>This would then provide Apache::Request, Apache::Cookie, and
>>>Apache::Upload. They'd be identical to the current
>>>Apache2:: modules in the multi-env branch.
>>
>>Or maybe let someone else split it off as a separate project
>>to just maintain those perl modules?
>
>
> Heh, that's what got us into this mess ;-).
> You still have to contend with libapreq1's existing
> modules, which are appropriately enjoying bitrot;
> but they aren't being eol'd.
Well, maybe splitting off Apache2::Request, Apache2::Upload,
Apache2::Cookie as a separate, perl project so that will just follow
libapreq2 and libapreq2 doesn't need to concern itself with them.
--
Michael Peters
Developer
Plus Three, LP
Re: [multi-env] perl glue status
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Michael Peters <mp...@plusthree.com> writes:
> Joe Schaefer wrote:
[...]
>> How about something like this?
>> use APR::Request::Apache2 compat => "apreq1";
>> This would then provide Apache::Request, Apache::Cookie, and
>> Apache::Upload. They'd be identical to the current
>> Apache2:: modules in the multi-env branch.
>
> Or maybe let someone else split it off as a separate project
> to just maintain those perl modules?
Heh, that's what got us into this mess ;-).
You still have to contend with libapreq1's existing
modules, which are appropriately enjoying bitrot;
but they aren't being eol'd.
--
Joe Schaefer
Re: [VOTE] Re: [multi-env] perl glue status
Posted by "Philip M. Gollucci" <pg...@p6m7g8.com>.
Michael Peters wrote:
>>Let's make a decision on this so we can move forward.
>>
>>I'm +1 for taking the above route. If the mod_perl team
>>rejects our Apache2::* modules after httpd has accepted
>>the C API, that's when I'll favor dropping those.
>>
>>
>
>+1
>
>
+1
--
END
-----------------------------------------------------------------------------
Philip M. Gollucci
Senior Developer - Liquidity Services Inc.
Phone: 202.568.6268 (Direct)
E-Mail: pgollucci@liquidation.com
Web: http://www.liquidation.com
Re: [VOTE] Re: [multi-env] perl glue status
Posted by Michael Peters <mp...@plusthree.com>.
Joe Schaefer wrote:
> Joe Schaefer <jo...@sunstarsys.com> writes:
>
>
>>Joe Schaefer <jo...@sunstarsys.com> writes:
>>
>>
>>>Ok, here's what I propose to do with the branch:
>>>
>>> 1) Move Apache2::Request::upload() to APR::Request::upload().
>
>
> [...]
>
>
>>OTOH, instead of (2), maybe we could continue to distribute them,
>>and transfer those to mp2 when the time is right. Would that make
>>more sense than dropping them right now?
>
>
> Let's make a decision on this so we can move forward.
>
> I'm +1 for taking the above route. If the mod_perl team
> rejects our Apache2::* modules after httpd has accepted
> the C API, that's when I'll favor dropping those.
+1
--
Michael Peters
Developer
Plus Three, LP
Re: [VOTE] Re: [multi-env] perl glue status
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Thu, 14 Apr 2005, Philip M. Gollucci wrote:
> Jonathan Vanasco wrote:
> > Wouldn't it make more sense to have APR as a namespace
> > under Apache/Apache2 ?
>
> I think you meant to say:
> Apache2::APR::*
The Apache/Apache2 top-level namespace usually is tied to
mod_perl, particularly mod_perl.so. However, although at
present the APR::* modules needed by apreq2 are contained
within the mp2 distribution, these particular modules can be
used without mod_perl.so (see the t/apr-ext tests in mp2).
This allows, for example, apreq2 to work within cgi scripts;
at one point, someone even got it to work with a non-Apache
web server.
--
best regards,
randy
Re: [VOTE] Re: [multi-env] perl glue status
Posted by "Philip M. Gollucci" <pg...@p6m7g8.com>.
Jonathan Vanasco wrote:
>Wouldn't it make more sense to have APR as a namespace under
Apache/Apache2 ?
I think you meant to say:
Apache2::APR::*
--
END
-----------------------------------------------------------------------------
Philip M. Gollucci
Senior Developer - Liquidity Services Inc.
Phone: 202.568.6268 (Direct)
E-Mail: pgollucci@liquidation.com
Web: http://www.liquidation.com
Re: [VOTE] Re: [multi-env] perl glue status
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Jonathan Vanasco <jv...@mastersofbranding.com> writes:
> Unless I'm mistaken, none of the perl glue works without mod_perl --
> so having Apache2/APR would logically chain the dependencies
You are mistaken. Most of the perl glue depends only on the APR stuff
in mod_perl. We already have stand-alone cgi tests for APR::Request::CGI.
--
Joe Schaefer
Re: [VOTE] Re: [multi-env] perl glue status
Posted by Jonathan Vanasco <jv...@mastersofbranding.com>.
Well, what I mean was really this:
Wouldn't it make more sense to have APR as a namespace under
Apache/Apache2 ?
Unless I'm mistaken, none of the perl glue works without mod_perl -- so
having Apache2/APR would logically chain the dependencies
I thought it was currently Apache::APR -- which makes sense to me.
From what I'm reading, it looks like the suggested change is to make
the APR library on the same node level as Apache
On Apr 14, 2005, at 1:13 PM, Joe Schaefer wrote:
> The other way, APR::Request::Apache2::upload(), might be possible;
> but that'd require adding Apache2::RequestRec to
> @APR::Request::Apache2::ISA.
> FWIW, I don't think that's a good idea, so unless upload() is 100%
> portable IMO it should stay where it is.
Re: [VOTE] Re: [multi-env] perl glue status
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Jonathan Vanasco <jv...@mastersofbranding.com> writes:
> On Apr 14, 2005, at 10:11 AM, Joe Schaefer wrote:
>>>> 1) Move Apache2::Request::upload() to APR::Request::upload().
>
> Can the perl glue be used outside of the mod_perl environment?
Hmm, looking at that upload() code, the only problem I see here
is with the $req->pool call in the last line. We don't provide
an pool struct anymore, so that call's inherited from Apache2::RequestRec.
So I guess moving upload() across to APR::Request::upload() is
a no-go for now; I'll just leave it where it is.
> If so, then I'm +1
>
> If not, would it be less confusing if it were
> Apache2::APR::Request::upload() ?
The other way, APR::Request::Apache2::upload(), might be possible;
but that'd require adding Apache2::RequestRec to @APR::Request::Apache2::ISA.
FWIW, I don't think that's a good idea, so unless upload() is 100%
portable IMO it should stay where it is.
--
Joe Schaefer
Re: [VOTE] Re: [multi-env] perl glue status
Posted by Jonathan Vanasco <jv...@mastersofbranding.com>.
On Apr 14, 2005, at 10:11 AM, Joe Schaefer wrote:
>>> 1) Move Apache2::Request::upload() to APR::Request::upload().
Can the perl glue be used outside of the mod_perl environment?
If so, then I'm +1
If not, would it be less confusing if it were
Apache2::APR::Request::upload() ?
Re: [VOTE] Re: [multi-env] perl glue status
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Geoffrey Young <ge...@modperlcookbook.org> writes:
> Joe Schaefer wrote:
>> If the mod_perl team
>> rejects our Apache2::* modules after httpd has accepted
>> the C API, that's when I'll favor dropping those.
>
> sorry for dropping in on the conversation at a very late date...
>
> what exactly might mod_perl reject? using the Apache2:: namespace
> without being a core mp2 module? I don't see a problem with that.
Me neither; I'm just trying to balance the decision-making
sequence so there's no pressure on any other communities to
make a hasty decision. We're sort of in a bind here with
the recent mp2 rename (our trunk is now defective, the
multi-env branch ain't ready yet, and our prior releases
don't work with mp2's latest candidate). IOW, the pressure
on *us* to release 2.05-dev has grown considerably now, but
that shouldn't negatively impact *other* ASF communities.
--
Joe Schaefer
Re: [VOTE] Re: [multi-env] perl glue status
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
Joe Schaefer wrote:
> If the mod_perl team
> rejects our Apache2::* modules after httpd has accepted
> the C API, that's when I'll favor dropping those.
sorry for dropping in on the conversation at a very late date...
what exactly might mod_perl reject? using the Apache2:: namespace without
being a core mp2 module? I don't see a problem with that.
--Geoff
[VOTE] Re: [multi-env] perl glue status
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Joe Schaefer <jo...@sunstarsys.com> writes:
> Joe Schaefer <jo...@sunstarsys.com> writes:
>
>> Ok, here's what I propose to do with the branch:
>>
>> 1) Move Apache2::Request::upload() to APR::Request::upload().
[...]
> OTOH, instead of (2), maybe we could continue to distribute them,
> and transfer those to mp2 when the time is right. Would that make
> more sense than dropping them right now?
Let's make a decision on this so we can move forward.
I'm +1 for taking the above route. If the mod_perl team
rejects our Apache2::* modules after httpd has accepted
the C API, that's when I'll favor dropping those.
--
Joe Schaefer
Re: [multi-env] perl glue status
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Joe Schaefer <jo...@sunstarsys.com> writes:
> Ok, here's what I propose to do with the branch:
>
> 1) Move Apache2::Request::upload() to APR::Request::upload().
>
> 2) Dump Apache2::*. mp2 should pick up those modules if/when httpd
> bundles an apreq2 in their distro.
>
> Comments?
OTOH, instead of (2), maybe we could continue to distribute them,
and transfer those to mp2 when the time is right. Would that make
more sense than dropping them right now?
--
Joe Schaefer
Re: [multi-env] perl glue status
Posted by Joe Schaefer <jo...@sunstarsys.com>.
"Philip M. Gollucci" <pg...@p6m7g8.com> writes:
> Joe Schaefer wrote:
>
>>"Philip M. Gollucci" <pg...@p6m7g8.com> writes:
>>
>>>Are you planning some nasty symbol table aliasing ?
>>
>>I'm planning to release 2.05-dev soon. The longer we go without
>>a concrete plan for the perl glue, the longer it'll take to get
>>this branch into trunk.
>>
>>Does that answer your question?
>>
>>
> Sort of.
Ok, here's what I propose to do with the branch:
1) Move Apache2::Request::upload() to APR::Request::upload().
2) Dump Apache2::*. mp2 should pick up those modules if/when httpd
bundles an apreq2 in their distro.
Comments?
--
Joe Schaefer
Re: [multi-env] perl glue status
Posted by "Philip M. Gollucci" <pg...@p6m7g8.com>.
> I've yet to see it compile all the way through :(
> Hopefully your last round on INS2PTR fixes will do it :)
Guess what .... It compiles!
[make test is failing... but I'll look into that]
Excellent work Joe!
END
------------------------------------------------------
Philip M. Gollucci (pgollucci@p6m7g8.com) 301.254.5198
Consultant / http://p6m7g8.net/Resume/resume.shtml
Senior Developer / Liquidity Services, Inc.
http://www.liquidityservicesinc.com
Re: [multi-env] perl glue status
Posted by "Philip M. Gollucci" <pg...@p6m7g8.com>.
Joe Schaefer wrote:
>"Philip M. Gollucci" <pg...@p6m7g8.com> writes:
>
>
>
>>>>How about something like this?
>>>>
>>>> use APR::Request::Apache2 compat => "apreq1";
>>>>
>>>>This would then provide Apache::Request, Apache::Cookie, and
>>>>Apache::Upload.
>>>>They'd be identical to the current
>>>>Apache2:: modules in the multi-env branch.
>>>>
>>>>
>>Are you planning some nasty symbol table aliasing ?
>>
>>
>
>I'm planning to release 2.05-dev soon. The longer we go without
>a concrete plan for the perl glue, the longer it'll take to get
>this branch into trunk.
>
>Does that answer your question?
>
>
Sort of.
I've yet to see it compile all the way through :(
Hopefully your last round on INS2PTR fixes will do it :)
I don't think it matters too much as the TRUNK never compiled for me either.
Its worlds closer though :)
--
END
-----------------------------------------------------------------------------
Philip M. Gollucci
Senior Developer - Liquidity Services Inc.
Phone: 202.568.6268 (Direct)
E-Mail: pgollucci@liquidation.com
Web: http://www.liquidation.com
Re: [multi-env] perl glue status
Posted by Joe Schaefer <jo...@sunstarsys.com>.
"Philip M. Gollucci" <pg...@p6m7g8.com> writes:
>>> How about something like this?
>>>
>>> use APR::Request::Apache2 compat => "apreq1";
>>>
>>> This would then provide Apache::Request, Apache::Cookie, and
>>> Apache::Upload.
>>> They'd be identical to the current
>>> Apache2:: modules in the multi-env branch.
>>
> Are you planning some nasty symbol table aliasing ?
I'm planning to release 2.05-dev soon. The longer we go without
a concrete plan for the perl glue, the longer it'll take to get
this branch into trunk.
Does that answer your question?
--
Joe Schaefer
Re: [multi-env] perl glue status
Posted by "Philip M. Gollucci" <pg...@p6m7g8.com>.
>> How about something like this?
>>
>> use APR::Request::Apache2 compat => "apreq1";
>>
>> This would then provide Apache::Request, Apache::Cookie, and
>> Apache::Upload. They'd be identical to the current
>> Apache2:: modules in the multi-env branch.
>
Are you planning some nasty symbol table aliasing ?
--
END
-----------------------------------------------------------------------------
Philip M. Gollucci
Senior Developer - Liquidity Services Inc.
Phone: 202.568.6268 (Direct)
E-Mail: pgollucci@liquidation.com
Web: http://www.liquidation.com
Re: [multi-env] perl glue status
Posted by Michael Peters <mp...@plusthree.com>.
Joe Schaefer wrote:
> Randy Kobes <ra...@theoryx5.uwinnipeg.ca> writes:
>
>
>>Perhaps apreq2 could provide a ::compat module, in the
>>spirit of mod_perl-2's Apache2::compat, to provide
>>a compatibility layer?
>
>
> How about something like this?
>
> use APR::Request::Apache2 compat => "apreq1";
>
> This would then provide Apache::Request, Apache::Cookie,
> and Apache::Upload. They'd be identical to the current
> Apache2:: modules in the multi-env branch.
Or maybe let someone else split it off as a separate project to just
maintain those perl modules?
--
Michael Peters
Developer
Plus Three, LP
Re: [multi-env] perl glue status
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Randy Kobes <ra...@theoryx5.uwinnipeg.ca> writes:
> Perhaps apreq2 could provide a ::compat module, in the
> spirit of mod_perl-2's Apache2::compat, to provide
> a compatibility layer?
How about something like this?
use APR::Request::Apache2 compat => "apreq1";
This would then provide Apache::Request, Apache::Cookie,
and Apache::Upload. They'd be identical to the current
Apache2:: modules in the multi-env branch.
--
Joe Schaefer
Re: [multi-env] perl glue status
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Markus Wichitill <ma...@gmx.de> 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
Re: [multi-env] perl glue status
Posted by Markus Wichitill <ma...@gmx.de>.
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.
>> 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.
Re: [multi-env] perl glue status
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Sat, 9 Apr 2005, Markus Wichitill wrote:
> Joe Schaefer wrote:
> > Not necessarily; we could backport apreq2 to mp1 and make your
> > conditional look something like this
>
> I'm less concerned about the conditional code, which is
> needed in lots of other places anyway, but more about the
> apreq2 API. That $body->param_class('APR::Request::Param')
> business just isn't very elegant, if it's indeed meant to
> be the final API for this purpose.
Perhaps apreq2 could provide a ::compat module, in the
spirit of mod_perl-2's Apache2::compat, to provide
a compatibility layer?
> > Then you can just forget about apreq1/Apache::Request, and use
> > apreq2/APR::Request everywhere. Of course mp2 will be a prereq
> > because we need some of the APR:: modules, but that shouldn't
> > be a problem now, because mp2 renamed their apis to allow parallel
> > installation of mp1+mp2.
>
> 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. Perhaps, after things settle down on
the mp2 side, we could look at this again.
--
best regards,
randy
Re: [multi-env] perl glue status
Posted by Markus Wichitill <ma...@gmx.de>.
Joe Schaefer wrote:
> Not necessarily; we could backport apreq2 to mp1 and make your
> conditional look something like this
I'm less concerned about the conditional code, which is needed in lots of
other places anyway, but more about the apreq2 API. That
$body->param_class('APR::Request::Param') business just isn't very elegant,
if it's indeed meant to be the final API for this purpose.
> Then you can just forget about apreq1/Apache::Request, and use
> apreq2/APR::Request everywhere. Of course mp2 will be a prereq
> because we need some of the APR:: modules, but that shouldn't
> be a problem now, because mp2 renamed their apis to allow parallel
> installation of mp1+mp2.
I doubt that any of my users will ever have such a setup, so I'll have to
continue support for plain mp1+apreq1.
Re: [multi-env] perl glue status
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Markus Wichitill <ma...@gmx.de> writes:
> Joe Schaefer wrote:
>> Instead of renaming, let's just toss Apache::Request and Apache::Cookie. At
>> the moment they're just stupid perl
>> modules wrapping APR::Request::Apache2 and APR::Request::Cookie.
>> I think we're better off developing the APR::Request namespace instead of
>> just renaming the old Apache:: APIs to Apache2::.
>
> Does that by any chance mean that I have to write ugly code such as
[...]
> in my upload scripts? If that's the case, I'd rather keep the wrapper
> classes .
Not necessarily; we could backport apreq2 to mp1 and make your
conditional look something like this
my $apreq_class = MP2 ? "APR::Request::Apache2" : "APR::Request::Apache";
my $req = $apreq_class->new($r, ...);
Then you can just forget about apreq1/Apache::Request, and use
apreq2/APR::Request everywhere. Of course mp2 will be a prereq
because we need some of the APR:: modules, but that shouldn't
be a problem now, because mp2 renamed their apis to allow parallel
installation of mp1+mp2.
I already put some apache1 backport code in multi-env/module/apache,
and I'm trying to figure out what to do with that.
--
Joe Schaefer
Re: [multi-env] perl glue status
Posted by Markus Wichitill <ma...@gmx.de>.
Joe Schaefer wrote:
> Instead of renaming, let's just toss Apache::Request and
> Apache::Cookie. At the moment they're just stupid perl
> modules wrapping APR::Request::Apache2 and APR::Request::Cookie.
> I think we're better off developing the APR::Request
> namespace instead of just renaming the old Apache:: APIs to Apache2::.
Does that by any chance mean that I have to write ugly code such as
if (MP1) {
$upload = $apr->upload('file');
$filename = $upload->filename();
$filesize = $upload->size();
}
elsif (MP2) {
require APR::Request::Param;
my $body = $apr->body;
$body->param_class('APR::Request::Param');
$upload = $body->get('file');
$filename = $upload->value();
$filesize = $upload->upload_size();
}
in my upload scripts? If that's the case, I'd rather keep the wrapper classes.
Re: [multi-env] perl glue status
Posted by "Philip M. Gollucci" <pg...@p6m7g8.com>.
Joe Schaefer wrote:
> Joe Schaefer <jo...@sunstarsys.com> writes:
>
>
>>Time to review, stabilize & document the perl glue.
>>The major change is the Apache:: -> Apache2:: rename.
>
>
> Instead of renaming, let's just toss Apache::Request and
> Apache::Cookie. At the moment they're just stupid perl
> modules wrapping APR::Request::Apache2 and APR::Request::Cookie.
> I think we're better off developing the APR::Request
> namespace instead of just renaming the old Apache:: APIs to Apache2::.
>
> Thoughts?
>
YES!
--
END
------------------------------------------------------
Philip M. Gollucci (pgollucci@p6m7g8.com) 301.254.5198
Consultant / http://p6m7g8.net/Resume/resume.shtml