APR, libapreq2, mod_perl2, APR::*, Apache2::*
Trying to locate APR::Request::Apache2 on my system, I noticed it is part of libapreq2. libapreq 2-2.07 | ModPerl | ModPerl http://www.gossamer-threads.com/lists/modperl/modperl/87199 | libapreq2 is an APR-based shared library used for parsing HTTP | cookies, query-strings and POST data. Doing further reading unearthes new ranges of modules, which has me somewhat confused. libapreq2 has modules like the following: * APR::Request * APR::Request::Cookie It is said to be closer to the bare metal. libapreq2 also has modules like the following: * Apache2::Request * Apache2::Cookie * Apache2::Upload It is said this is to mimic the 1.x API. Without libapreq2, I already have: * Apache2::RequestRec * Apache2::RequestIO * Apache2::RequestUtil It is said this is to only load what's needed. I'd like to reach an understanding of what these ranges of modules and interfaces are intended for. When would I want to use which interface? Or is it all a matter of style and taste? Michael Ludwig
Re: APR, libapreq2, mod_perl2, APR::*, Apache2::*
Michael Ludwig wrote: > I'd like to reach an understanding of what these ranges of modules and > interfaces are intended for. When would I want to use which interface? > Or is it all a matter of style and taste? Possibly. You will need the standard modperl2 library to even get modperl up and running. I would recommend installing libapreq2 as well, as it exposes more functionalities that you will very likely use (especially if you're used to CGI).
Re: APR, libapreq2, mod_perl2, APR::*, Apache2::*
Foo JH schrieb: Michael Ludwig wrote: I'd like to reach an understanding of what these ranges of modules and interfaces are intended for. When would I want to use which interface? Or is it all a matter of style and taste? Possibly. You will need the standard modperl2 library to even get modperl up and running. I would recommend installing libapreq2 as well, as it exposes more functionalities that you will very likely use (especially if you're used to CGI). Or mod_perl 1.0, for that matter. Thanks for your answer, it clarifies things a bit for me, as does this thread: How to extract name/value pairs from the query string? | ModPerl http://www.gossamer-threads.com/lists/modperl/modperl/98100 Turns out either the CGI module or libapreq2 is necessary for parsing the query string. I was expecting that functionality in one of Apache2::RequestRec, or Apache2::RequestUtil, or maybe just Apache2 (which doesn't exist). It is said in the thread referred to above that "the splitting of the APIs [...] is strange and confusing", and coming from mod_perl 1.0, I agree. But it probably has advantages as well. Michael Ludwig
Re: APR, libapreq2, mod_perl2, APR::*, Apache2::*
Michael Ludwig wrote: It is said in the thread referred to above that "the splitting of the APIs [...] is strange and confusing", and coming from mod_perl 1.0, I agree. But it probably has advantages as well. i think that comment about splitting the api was with respect to RequestRec, RequestUtil, RequestIO, not really to do with Apache2::Request. Apache::Request for mp1 is a part of libapreq, just as Apache2::Request is part of libapreq2. Maybe you realized that and i'm just misunderstanding though. Personally, i think libapreq should be part of core httpd (or at least a 'normal' module, and libapreq2's perl bindings should be part of stock mod_perl. Adam
Re: APR, libapreq2, mod_perl2, APR::*, Apache2::*
Adam Prime wrote: Personally, i think libapreq should be part of core httpd (or at least a 'normal' module, and libapreq2's perl bindings should be part of stock mod_perl. Oh, but we started work for this in 2.4 of httpd for libapreq.so and mod_apreq.so for http core. after httpd 2.6/3.0 we might be able to swing the perl bindings peices. See: Subject: Food for thought / looking for something to do thead on d...@perl.a.o from ~11/10/08 -- 1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C Philip M. Gollucci (pgollu...@p6m7g8.com) c: 703.336.9354 Consultant - P6M7G8 Inc.http://p6m7g8.net Senior Sys Admin- RideCharge, Inc. http://ridecharge.com Contractor - PositiveEnergyUSA http://positiveenergyusa.com ASF Member - Apache Software Foundation http://apache.org FreeBSD Committer - FreeBSD Foundation http://freebsd.org Work like you don't need the money, love like you'll never get hurt, and dance like nobody's watching.
Re: APR, libapreq2, mod_perl2, APR::*, Apache2::*
Adam Prime schrieb: Michael Ludwig wrote: It is said in the thread referred to above that "the splitting of the APIs [...] is strange and confusing", and coming from mod_perl 1.0, I agree. But it probably has advantages as well. i think that comment about splitting the api was with respect to RequestRec, RequestUtil, RequestIO, not really to do with Apache2::Request. I guess you're right. Apache::Request for mp1 is a part of libapreq, just as Apache2::Request is part of libapreq2. Maybe you realized that and i'm just misunderstanding though. I didn't - thanks for pointing this out. I wasn't aware any more, and maybe have never been, that Apache::Request was part of libapreq. Michael Ludwig
Re: APR, libapreq2, mod_perl2, APR::*, Apache2::*
Philip M. Gollucci wrote: Oh, but we started work for this in 2.4 of httpd for libapreq.so and mod_apreq.so for http core. cool after httpd 2.6/3.0 we might be able to swing the perl bindings peices. So where does that leave the perl binding between 2.4 and 3.0? Or will we all be running mod_parrot/mod_perl6 by then (which looks like it's made great progress since YAPC) Adam
Re: APR, libapreq2, mod_perl2, APR::*, Apache2::*
Adam Prime wrote: Philip M. Gollucci wrote: Oh, but we started work for this in 2.4 of httpd for libapreq.so and mod_apreq.so for http core. cool after httpd 2.6/3.0 we might be able to swing the perl bindings peices. So where does that leave the perl binding between 2.4 and 3.0? Or will we all be running mod_parrot/mod_perl6 by then (which looks like it's made great progress since YAPC) Adam Its quite complex and I'm not sure API/ABI and all that and combinations of module A. Given apr, apr-util, httpd (2.0.x,2.2.x, mpms) perl (5.6.x, 5.8.x, 5.10.x) mod_perl 2.0.4 and libapreq2.08 we support well over 2k combinations. I'm not sure I want to fork libapreq2 and have even more. We really need more people then me following d...@httpd.a.o -- 1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C Philip M. Gollucci (pgollu...@p6m7g8.com) c: 703.336.9354 Consultant - P6M7G8 Inc.http://p6m7g8.net Senior Sys Admin- RideCharge, Inc. http://ridecharge.com Contractor - PositiveEnergyUSA http://positiveenergyusa.com ASF Member - Apache Software Foundation http://apache.org FreeBSD Committer - FreeBSD Foundation http://freebsd.org Work like you don't need the money, love like you'll never get hurt, and dance like nobody's watching.
Re: APR, libapreq2, mod_perl2, APR::*, Apache2::*
On Thu, 8 Jan 2009, Adam Prime wrote: > Personally, i think libapreq should be part of core httpd > (or at least a 'normal' module, and libapreq2's perl > bindings should be part of stock mod_perl. Yeah I've run into systems multiple times where the boss was too afraid of change to allow building libapreq2... like on CentOS, where the perl bindings to APR don't appear to be available and have to be built, which requires the dev packages... and the dev packages require a server upgrade which isn't allowed because (fear of the unknown) it might cause problems with existing applications. :-/ It would be awesome if the libapreq2 modules installed with mod_perl2, since they are so useful to applications, and it's tiring to explain these things and useless to say that the chosen OS flavor is lame. > So where does that leave the perl binding between 2.4 and > 3.0? Or will we all be running mod_parrot/mod_perl6 by > then (which looks like it's made great progress since > YAPC) Great, all code where '.' was the concatenator operator breaks, hurray. (?) Mark
Re: APR, libapreq2, mod_perl2, APR::*, Apache2::*
Mark Hedges wrote: So where does that leave the perl binding between 2.4 and 3.0? Or will we all be running mod_parrot/mod_perl6 by then (which looks like it's made great progress since YAPC) Great, all code where '.' was the concatenator operator breaks, hurray. (?) You don't have to switch if you don't want to, it's not like mod_perl (or perl 5) is going to disappear from production anytime soon. I'm just glad that someone (Jeff Horwitz) is actually already working on it, because to me, perl6 without a mod_perl6 is close to useless. I'm also hopeful that the eventual migration might be as simple as the oft dreaded migration from mp1, mp2 (ie not all that hard). Only time will tell. Adam
