You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Perrin Harkins <pe...@elem.com> on 2003/10/15 20:53:44 UTC
ModPerl::Registry vs. Apache::compat
I recently gave some advice on perlmonks.org to a person who was
concerned about what his migration path would be if he develops for
mod_perl 1 right now. I told him he will be safe if he uses
Apache::Registry, since he should be able to run his A::R scripts under
ModPerl::Registry unchanged (assuming he does the workaround for chdir
and uses prefork).
Another person suggested coding to the mp 1 handler API and using
Apache::compat to port. I thought that would be slow and potentially
bad in terms of memory used, but I'm not actually certain how these two
options compare. Does anyone have any information about the comparison
of ModPerl::Registry and Apache::compat in terms of performance, memory,
and ease of porting? I'd like to make sure I give good advice on this
topic.
- Perrin
Re: ModPerl::Registry vs. Apache::compat
Posted by Josh Chamas <jo...@chamas.com>.
Perrin Harkins wrote:
> I recently gave some advice on perlmonks.org to a person who was
> concerned about what his migration path would be if he develops for
> mod_perl 1 right now. I told him he will be safe if he uses
> Apache::Registry, since he should be able to run his A::R scripts under
> ModPerl::Registry unchanged (assuming he does the workaround for chdir
> and uses prefork).
>
> Another person suggested coding to the mp 1 handler API and using
> Apache::compat to port. I thought that would be slow and potentially
> bad in terms of memory used, but I'm not actually certain how these two
> options compare. Does anyone have any information about the comparison
> of ModPerl::Registry and Apache::compat in terms of performance, memory,
> and ease of porting? I'd like to make sure I give good advice on this
> topic.
>
> - Perrin
>
Another approach is to use an application framework that hides the
internals of mod_perl under its APIs like Apache::ASP. An application
written for Apache::ASP will work the same under mod_perl 1 as it
does under mod_perl 2 provided mod_perl APIs are not directly invoked.
I am guessing that the same would be true for using CGI.pm under mod_perl,
Template Toolkit, etc. I am not sure generally if this is true for
all application environments yet though, as I am not sure about whether
they have all been ported to work under mod_perl 2 yet.
Regards,
Josh
________________________________________________________________
Josh Chamas, Founder phone:925-552-0128
Chamas Enterprises Inc. http://www.chamas.com
NodeWorks Link Checker http://www.nodeworks.com
Re: ModPerl::Registry vs. Apache::compat
Posted by Stas Bekman <st...@stason.org>.
Perrin Harkins wrote:
> Geoffrey Young wrote:
>
>> so I see no harm in letting the masses get their feet wet with 2.0
>> now. we have lots of people installing it on lots of different
>> platforms, so getting past the initial installation hurdle shouldn't
>> be any more difficult than with 1.0. after that, the main API hasn't
>> changed much, so the documentation for 1.0 is still farily relevant
>> (once you get past loading all those classes).
>
>
> That's actually the reason I didn't recommend starting with mp2 to this
> guy: the documentation.
That's really not an issue. They can always ask at the list and we usually
answer pretty quickly if we are around. Same as with the code, there are too
many things to document, so those who ask for a specific missing documentation
will get it first.
Also I hope that people will help us to port the docs from mp1. After all,
it's not like writing from scratch, it's just verifying that things haven't
changed and copying big chunks of docs mostly unmodified.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: ModPerl::Registry vs. Apache::compat
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> That's actually the reason I didn't recommend starting with mp2 to this
> guy: the documentation. It's easy for me to look at things and say "oh,
> this corresponds to the 1.0 docs here", but to a newbie that will sound
> like insanity. There's a lot more documented than there used to be, and
> I am in no position to criticize anyone else's efforts, having done very
> little to contribute to the 2.0 docs at this point, but this is the
> thing that holds me back from recommending it to newbies.
I think that's true to a point. however, if the user wants to do
authentication and goes to the eagle book or cookbook to see how it's done,
it's still $r->get_basic_auth_pw and $r->note_basic_auth_failure, whether
it's mod_perl 1.0 or 2.0.
the issue is finding them in 2.0 when they used to just be there in 1.0.
Apache::porting seems to be a good way to go in this respect, but I haven't
tried it myself. but I have tried to do my part
http://www.perl.com/pub/a/2003/04/17/filters.html
tries to explain some of the new classes you need to use(), what they do,
and how to go about finding what you need. it's not much, but I hope it
helps at least a few get started.
> Well, that
> and concerns about the safety of Perl threads at this point, but that's
> easy to avoid by using pre-fork.
:)
--Geoff
Re: ModPerl::Registry vs. Apache::compat
Posted by Perrin Harkins <pe...@elem.com>.
Geoffrey Young wrote:
> so I see no harm in letting the masses get their feet wet with 2.0 now.
> we have lots of people installing it on lots of different platforms, so
> getting past the initial installation hurdle shouldn't be any more
> difficult than with 1.0. after that, the main API hasn't changed much,
> so the documentation for 1.0 is still farily relevant (once you get past
> loading all those classes).
That's actually the reason I didn't recommend starting with mp2 to this
guy: the documentation. It's easy for me to look at things and say "oh,
this corresponds to the 1.0 docs here", but to a newbie that will sound
like insanity. There's a lot more documented than there used to be, and
I am in no position to criticize anyone else's efforts, having done very
little to contribute to the 2.0 docs at this point, but this is the
thing that holds me back from recommending it to newbies. Well, that
and concerns about the safety of Perl threads at this point, but that's
easy to avoid by using pre-fork.
- Perrin
Re: ModPerl::Registry vs. Apache::compat
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
>> It's kind of a tough call what to recommend. He's a mod_perl newbie, so
>> I don't feel comfortable suggesting he start with mp 2 at the moment.
>> Ultimately the best approach is probably to write for mp 1 now, and port
>> it in a few years with the help of compat, but Registry is a tempting
>> alternative for applications that are not really using the Apache API.
>
>
> Not at all, mp2 1.99_10 is very robust (at least according to our test
> suite), and the we mainly haven't finalized the API for new features,
> the features coming from mp1 are pretty much the same (assuming Apache
> 2.0 kept the API) and won't change. Since most people want mod_perl for
> its PerlResponseHandler I think most newbies will be just fine with mp2,
> while using the books/docs for mp1 and what's available for mp2.
> Especially as you mention for Registry scripts.
I can echo that.
in my mind, mod_perl 1.0 as the stable version means that 1.0 is the version
you use for mission critical applications - ones where your business depends
on your web presence, and where going down, ever, means very bad things.
now, I doubt that newbies will be developing software that fits into that
category - at least I didn't when I was getting into it at first, and I
wouldn't trust my mission critical applications to a technology developers
weren't familiar with.
so, that leaves newbies as hobbyists or developers of small deployments.
mod_perl 2.0 at the point where it is probably usable for this: nearing
feature completion and appearing somewhat dependable in almost-real-world
situations to us developers.
so I see no harm in letting the masses get their feet wet with 2.0 now. we
have lots of people installing it on lots of different platforms, so getting
past the initial installation hurdle shouldn't be any more difficult than
with 1.0. after that, the main API hasn't changed much, so the
documentation for 1.0 is still farily relevant (once you get past loading
all those classes).
on a self-serving note to those of us that work on 2.0: 2.0 isn't going to
reach "enterprise" readiness until people start banging on it regularly in
small deployments, graduating to larger deployments as issues are reported
and fixed. and getting people past the "it's not ready" stigma is the first
stage - it's probably time to get behind mod_perl 2.0 as as good a place as
any to start.
just my humble opinion...
--Geoff
Re: ModPerl::Registry vs. Apache::compat
Posted by Stas Bekman <st...@stason.org>.
Perrin Harkins wrote:
> On Wed, 2003-10-15 at 15:13, Stas Bekman wrote:
>
>>The biggest problem with Apache::compat is that it modifies the behavior of
>>several methods to behave like they did in mp1. So if you run on the same
>>server some code that relies on their mp2 behavior, there is a conlict.
>
>
> That makes sense. So, it can be difficult to move code over one piece
> at a time in this way because using Apache::compat can prevent your
> ported code from working.
True. Perhaps we need to move those methods into another module, or have a
special import() rule to enable them. Josh has suggested categories some time
ago, but nobody implemented them, so it remains an idea. Scott has suggested
using source filter to scope the usage of the APIs coming from Apache::compat,
(ala use/no Apache::compat), but neither I or someone else had a chance to
implement the suggested technique.
>>Besides that memory-wise it'll just load all the modules that it needs, so you
>>might get some unneeded modules loaded, which shouldn't be much of a problem.
>
>
> That's what I figured. I don't have a mp 2 build handy at the moment to
> try this with, but I'm assuming it's not a big hit because the modules
> are at least preloaded.
That's correct.
> It's kind of a tough call what to recommend. He's a mod_perl newbie, so
> I don't feel comfortable suggesting he start with mp 2 at the moment.
> Ultimately the best approach is probably to write for mp 1 now, and port
> it in a few years with the help of compat, but Registry is a tempting
> alternative for applications that are not really using the Apache API.
Not at all, mp2 1.99_10 is very robust (at least according to our test suite),
and the we mainly haven't finalized the API for new features, the features
coming from mp1 are pretty much the same (assuming Apache 2.0 kept the API)
and won't change. Since most people want mod_perl for its PerlResponseHandler
I think most newbies will be just fine with mp2, while using the books/docs
for mp1 and what's available for mp2. Especially as you mention for Registry
scripts.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: ModPerl::Registry vs. Apache::compat
Posted by Perrin Harkins <pe...@elem.com>.
On Wed, 2003-10-15 at 15:13, Stas Bekman wrote:
> The biggest problem with Apache::compat is that it modifies the behavior of
> several methods to behave like they did in mp1. So if you run on the same
> server some code that relies on their mp2 behavior, there is a conlict.
That makes sense. So, it can be difficult to move code over one piece
at a time in this way because using Apache::compat can prevent your
ported code from working.
> Besides that memory-wise it'll just load all the modules that it needs, so you
> might get some unneeded modules loaded, which shouldn't be much of a problem.
That's what I figured. I don't have a mp 2 build handy at the moment to
try this with, but I'm assuming it's not a big hit because the modules
are at least preloaded.
It's kind of a tough call what to recommend. He's a mod_perl newbie, so
I don't feel comfortable suggesting he start with mp 2 at the moment.
Ultimately the best approach is probably to write for mp 1 now, and port
it in a few years with the help of compat, but Registry is a tempting
alternative for applications that are not really using the Apache API.
Anyway, thanks for the input.
- Perrin
Re: ModPerl::Registry vs. Apache::compat
Posted by Stas Bekman <st...@stason.org>.
Perrin Harkins wrote:
> I recently gave some advice on perlmonks.org to a person who was
> concerned about what his migration path would be if he develops for
> mod_perl 1 right now. I told him he will be safe if he uses
> Apache::Registry, since he should be able to run his A::R scripts under
> ModPerl::Registry unchanged (assuming he does the workaround for chdir
> and uses prefork).
>
> Another person suggested coding to the mp 1 handler API and using
> Apache::compat to port. I thought that would be slow and potentially
> bad in terms of memory used, but I'm not actually certain how these two
> options compare. Does anyone have any information about the comparison
> of ModPerl::Registry and Apache::compat in terms of performance, memory,
> and ease of porting? I'd like to make sure I give good advice on this
> topic.
Apache::compat's usage should be avoided in production if possible at the
moment, other than during initial porting. So if that's the case, the issues
of performance and memory moot ;) If not, please read on.
The biggest problem with Apache::compat is that it modifies the behavior of
several methods to behave like they did in mp1. So if you run on the same
server some code that relies on their mp2 behavior, there is a conlict.
Besides that memory-wise it'll just load all the modules that it needs, so you
might get some unneeded modules loaded, which shouldn't be much of a problem.
Performance-wise, some to the previously implemented in C methods, are now
implemented in Perl, so the speed will be affected. This is only true for
methods which no longer exist in Apache 2.0 C API. So one will have to check
what methods they are using in order to judge the performance impact.
Personally, I'm now using the new module Apache::porting, which assists in
moving to the mp2 API, not providing a back-compat with mp1 API.
http://perl.apache.org/docs/2.0/api/Apache/porting.html
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com