Besides comments below, I think we shouldn't support:
Apache->server_root_relative and equivalents, but only:
($r|$s|$c)->server_root_relative(...) and Apache::server_root_relative($pool, ...)
because users will get bad memory leaks when a global pool is used to allocate memory in requests. We should support the non-(pool|$r|$c|$s) argument functions only in compat and may be even print a warning when used for the first time.
What do you think?
sounds fine to me. the functional no-args for was bothersome to me anyway, and this makes coding it easier.
great!
I don't think the non-Server functions belong here. They should go into
respective xs/Apache/ files.
I did try that, but I couldn't seem to get to mpxs_ap_server_root_relative from the other .h files. but then I thought it was ok - there are lots of examples where .h files are used to define methods for other classes, especially the util classes. for instance Apache::server_root_relative lives in Apache__ServerUtil.h, Apache::RequestRec::as_string lives in Apache__RequestUtil.h, etc.
Yes, but but notice that as_string is still operating on /Request/, whereas your patch was putting request and connection methods into a /Server/. Not good.
I'm not sure about the include to reuse the definition, but it's really a one-liner, which can be #defined too:
#define mpxs_ap_server_root_relative(sv, fname) \
newSVpv(ap_server_root_relative(modperl_sv2pool(aTHX_ sv), fname), 0);so may be add it to xs/modperl_xs_util.h, which is alredy included.
__________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
