mod_perl2 design - what are the Ways To Do It ?

yosefm has asked for the wisdom of the Perl Monks concerning the following question:

I had an application made of several modules and several CGI scripts that used them. Lately I moved my computer from RedHat to Gentoo Linux, and did a lousy job in backing up, so I have my modules but not the scripts.

I figured this would be a good time to use a more up-to-date technology, and I have been doing a lot of research on mod_perl 2, Which brought up some questions that were not answered for me as well as I'd like - the whole thing is pretty confusing, considering that: the thing is still in development; I've never used mod_perl before.

So, after a long rout of googling, searchin, reading tutorials, trying and trying again (my apache2 processes are forming a union, I abused it so much :) ), I guess I'll have to come to the true source of perl wisdom... The questions I have, in short are these:

What design do you use for your mod_perl scripts? Is it anything like CGI::Application or anything I am familiar with from the mod_cgi world?
Handlers vs. ModPerl::Registry: What are the pros/cons of using each?
What is the status of libapreq2? I saw on CPAN that it's in a development phase (ends with _04). I searched for more info on it, but couldn't find any. Is it very important? Should I wait for it, or should I use substitues (I see on the web that using CGI::* is just enough, but if I'm going for the new technology, I want to make sure that I'm up-to-date).

A final point is that I care nothing about stability and reliability. This is for my family, and is mainly a training project for me.

Thanks.

perl -e'$b=unpack"b*",pack"H*","59dfce2d6b1664d3b26cd9969503";\
for(;$a<length$b;$a+=9){print+pack"b8",substr$b,$a,8;}'
[download]

My public key

Comment on mod_perl2 design - what are the Ways To Do It ? Download Code

Replies are listed 'Best First'.
Re: mod_perl2 design - what are the Ways To Do It ? by dragonchild (Archbishop) on Jun 16, 2004 at 17:25 UTC
I am not a mod_perl guru by any means, but I have recently deployed a relatively large app from the ground up using MP2. There are (at least!) two different ways to handle a request using mod_perl. The first is using mod_perl handlers and the other is using CGI scripts. I use ModPerl::Registry and it works really well. I have them running large CGI::Application classes and it's great! Speed boosts are great. MP handlers are Perl classes that have access to the Apache internals to do their business. They are very very very fast. They also have a very different interface, which also isn't fully finished. (There recently was a major API change in the latest mod_perl 1.99_x release.) I, personally, would wait until there is a mod_perl 2.0_x release before writing handlers against it, but that's just me. Now, from what I've read, it seems possible to have CGI::Application classes be mod_perl handlers, but I haven't seen anyone else do it, so I don't know if I'm stunningly brilliant or just missing something. ------ We are the carpenters and bricklayers of the Information Age. Then there are Damian modules.... sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon.* - flyingmoose I shouldn't have to say this, but any code, unless otherwise stated, is untested	[reply]
Re: mod_perl2 design - what are the Ways To Do It ? by Arunbear (Prior) on Jun 16, 2004 at 20:15 UTC
I have used CGI::Application with Modperl::Registry and agree that it is a great combination. Another alternative is to use a framework which supplies the mod_perl handlers thus simplifying your work, e.g. HTML::Mason, Maypole, Axkit to name a few (though I'm not sure if these have been tested with MP2). BTW, if it is for family, why are stability and reliability not important?	[reply]
Re^2: mod_perl2 design - what are the Ways To Do It ? by yosefm (Friar) on Jun 17, 2004 at 09:46 UTC
Thanks, I'll look into those. stability and reliability are not important because my family is not going to sue my ass if something goes wrong, so I can test whatever I want. `perl -e'$b=unpack"b",pack"H","59dfce2d6b1664d3b26cd9969503";\ for(;$a<length$b;$a+=9){print+pack"b8",substr$b,$a,8;}'` [download] My public key	[reply] [d/l]
Re: mod_perl2 design - what are the Ways To Do It ? by hardburn (Abbot) on Jun 16, 2004 at 18:11 UTC
If you only use ModPerl::Registry, you're doing fine. However, you won't be taking full advantage of mod_perl (either v2 or the equivilent for v1). A full handler gives you an awful lot of flexibility. In mod_perl2, you aren't even limited to handling just HTTP--just about any protocol implemented with TCP can be done. Maybe you won't need that extra flexibility, but you can do a lot of fun things with it. Note that the CGI::* namespace is mostly notation. While some of it may not be applicable to a mod_perl environment, some of it is generic enough to be used under either mod_perl or mod_cgi. OTOH, some of them should be ditched in favor of mod_perl-specific modules. For instance, CGI.pm itself should probably be skipped in favor of Apache::Request, at least for parsing CGI params and setting headers. ---- send money to your kernel via the boot loader.. This and more wisdom available from Markov Hardburn.	[reply]
Re^2: mod_perl2 design - what are the Ways To Do It ? by yosefm (Friar) on Jun 16, 2004 at 19:03 UTC
But some of the apache-specific modules haven't been ported yet... right? Question is, should I wait for the port, or just move my code to them when they are ported to perl6 ? (in other words, are they comming soon?) `perl -e'$b=unpack"b",pack"H","59dfce2d6b1664d3b26cd9969503";\ for(;$a<length$b;$a+=9){print+pack"b8",substr$b,$a,8;}'` [download] My public key	[reply] [d/l]
Re^3: mod_perl2 design - what are the Ways To Do It ? by hardburn (Abbot) on Jun 16, 2004 at 19:09 UTC
I don't see where Perl6 comes into it. Both branches of mod_perl are working off Perl5 and will probably continue to do so for some time. There is a mod_parrot project underway, though. IMHO, working at the Parrot level makes more sense, as it gives Apache integration with a bunch of other languages for free. You are correct that not all the old modules work on mod_perl2 yet. You need to ask yourself if you need to use any of the modules that don't currently work. If not, then go ahead and use mod_perl2. If so, you must either use mod_perl1, be willing to put effort into porting those modules, or wait. ---- send money to your kernel via the boot loader.. This and more wisdom available from Markov Hardburn.	[reply]
Re^4: mod_perl2 design - what are the Ways To Do It ? by yosefm (Friar) on Jun 17, 2004 at 09:34 UTC
Re: mod_perl2 design - what are the Ways To Do It ? by yosefm (Friar) on Jun 18, 2004 at 19:01 UTC
Well, after reading all of your comments, I finally decided to go with CGI::Application. I even looked at the MovableType source and found how to use my app class as a handler, so I don't use ModPerl::Registry. Thanks for all the commenters. `perl -e'$b=unpack"b",pack"H","59dfce2d6b1664d3b26cd9969503";\ for(;$a<length$b;$a+=9){print+pack"b8",substr$b,$a,8;}'` [download] My public key	[reply] [d/l]


more useful options
	PerlMonks