|
Re: Perl vs. ModPerl
by grep (Monsignor) on May 31, 2002 at 01:59 UTC
|
mod_perl is an embedded perl interpreter inside Apache.
So to answer your question
Is modperl just a way of invoking Perl scripts using the same process, saving the startup cost?
Not really, that is just an advantage of having a perl interpeter embedded in your webserver
Check out the docoumentation at perl.apache.org especially the the mod_perl Guide.
grep
|
These are not the monks you are looking for, move along |
| [reply] |
Re: Perl vs. ModPerl
by perrin (Chancellor) on May 31, 2002 at 03:48 UTC
|
The thing is, writing for mod_perl well requires understanding of some other things, like memory management and the Apache process model. CGI is much more forgiving of sloppy code as well. Writing for mod_perl usually means using strict, writing modules, etc. | [reply] |
|
|
If you have basic knowledge of packages and perl itself, mod_perl development isn't that hard :) well, just like regular perl, I guess. It's only when you spend a little time with it, that you realize the tweaks here and the speedups there...
Greetz
Beatnik
... Quidquid perl dictum sit, altum viditur.
| [reply] |
Re: What is mod_perl
by cjf (Parson) on May 31, 2002 at 02:07 UTC
|
| [reply] |
|
|
The "mod_perl Developer's Cookbook" (Sams) and "Writing Apache Modules with Perl and C" (O'Reilly) are both available now.
| [reply] |
Re: Perl vs. ModPerl
by Matts (Deacon) on May 31, 2002 at 06:38 UTC
|
I'm biased, but I think the best and most succinct writing about this is the introductory "What is mod_perl" on take23. I think it should cover everything you need to know. | [reply] |
Re: Perl vs. ModPerl
by alien_life_form (Pilgrim) on May 31, 2002 at 10:57 UTC
|
Greetings,
In fact, you can use mod_perl simply as a CGI accelerator by running under Apache::Registry,or even - egads! - under the wily Apache::PerlRun. In the second case, you would be using mod_perl in a way that's very close to the way you described.
Apache::Registry scripts also cache a compiled version of your code, achieving a much better speed up, but only the cleanest and better structured CGI programs will run without modification under Apache::Registry.
And, as others mentioned, there's much, much more to mod_perl, and the SAMS book "the mod_perl developers' cookbook" is a fantastic guide to it.
Cheers,
alf
You can't have everything: where would you put it? | [reply] |
|
|
only the
cleanest and better structured CGI programs will run without modification under Apache::Registry.
...and they should all be that clean and well-structured.
(I see this the opposite way, alien_life_form - only
sloppy code fails under Apache::Registry.)
| [reply] |
|
|
Greetings,
You are right - in fact I tend to think so myself, and would have written as much, except for the embedded subroutine trap which does not necessarily mean the starting code was sloppy...
BUt apart from that (which is avoided by using packages, arguably a way of achieving better code structure), I have from some time decided to write modperl-compliant CGI code even when I know it will never run under modperl....
call it the superstrict pragma, if you wish ;)
Cheers,
alf
You can't have everything: where would you put it?
| [reply] |
Re: Perl vs. ModPerl
by Anonymous Monk on May 31, 2002 at 20:36 UTC
|
O.K. I'll grant that people responded with links to pages that explain it better. But I can't believe noone mentioned the coolest aspect of mod_perl. It is that it serves as an API into the internals of apache. You can completely control just about everything apache does with perl code, 8^) | [reply] |
