Re: mod_perl: Is it so necessary?
by merlyn (Sage) on Sep 05, 2000 at 09:27 UTC
|
CGI is simple, easy to understand, and fairly portable, since it's just an interface
between the web server and a child process that reads the environment and standard
input, and provides a simple text interface on standard output.
But to get performance, we can't fork on each request. That's the death knell.
So many "servlet"-type solutions have arisen, with probably the most popular
being the mod_perl under Apache. After all, that's what The Monestary
uses. {grin}
-- Randal L. Schwartz, Perl hacker | [reply] [Watch: Dir/Any] |
RE: mod_perl: Is it so necessary?
by KM (Priest) on Sep 05, 2000 at 18:46 UTC
|
It isn't that it is inadequate (CGI/Perl, that is), but rather that many applications may not need mod_perl. A simple guestbook, file manager, calendar, etc... may not need the speed enhancements, caching, response/logging phase massaging, etc... that mod_perl provides. mod_perl does add some bloat, which isn't always needed.
People need to do things with the right tools, and mod_perl is Just Another Tool. It is also a valuable tool which provides functionalities which 'regular' CGI/Perl does not. Or at least provides a more efficient way to do some things (for example, you *can* write to the http log file with CGI/Perl, but mod_perl provides a better way).
Whenever speed/response time is an issue with a CGI application, you should take mod_perl (or fastCGI) into account and see if those tools will help build a better web application.
Cheers,
KM | [reply] [Watch: Dir/Any] |
Re: mod_perl: Is it so necessary?
by cianoz (Friar) on Sep 05, 2000 at 17:49 UTC
|
you wrote: Also, I would like to know if the CGI/PERL combination is so inadequate, why would anyone be spending any time developing in it?
Immagine you have to run the script with a different UID
from that of the web server: a cgi script can be run suid,
instead a mod_perl script runs inside the httpd process
with the same UID.
an other reason could be portability:
cgi run almost everywhere, if you don't control the server where your script run maybe your oly choice is cgi.
| [reply] [Watch: Dir/Any] |
Re: mod_perl: Is it so necessary?
by Anonymous Monk on Sep 05, 2000 at 12:56 UTC
|
You wrote:
I wonder how many of my scripts I will have to re-write.
you can run your cgi scripts under Apache::Registry
without changes taking advandage of persistent
DB connections, fast startup etc.
(whell, if the script run clean under "use strict"
then it will do also under Apache::Registry...)
| [reply] [Watch: Dir/Any] |
|
if the script run clean under "use strict" then it will
do also under Apache::Registry...
Well, this is not necessary true. For example, my() scoped
variables in nested subroutines are a problem. See the
relevant section in the
mod_perl guide.
You might also look at Training wheels again why it is better to rewrite
CGI scripts to modperl apps. The mod_perl guide has
a nice section about tuning, too.
| [reply] [Watch: Dir/Any] |
Re: mod_perl: Is it so necessary?
by TheoPetersen (Priest) on Sep 06, 2000 at 00:12 UTC
|
Before moving a script to Apache::Registry (or rewriting it as a mod_perl module)
ask yourself: do all my Apache child processes need this? If the answer is yes, then
go ahead; if not, leave it as a simple CGI.
Since Apache::Registry caches compiled scripts (well, it just leaves them compiled, more accurately)
and mod_perl never releases compiled code (any more than a regular Perl interpreter does)
anything you run either way is going to add memory for the life of the child it runs in.
Occasional admin scripts, once-a-day statistics and that sort of thing should remain plain CGI
for that reason.
..Theo | [reply] [Watch: Dir/Any] |
Re: mod_perl: Is it so necessary?
by Anonymous Monk on Sep 06, 2000 at 00:10 UTC
|
Don't know about mod_perl, but one reason NOT to use DBI is that it may not exist on your target machine. Some of my scripts broke this morning when I moved them from development to production. It turns out that the production machine did not have DBI installed.
Fortunately the 'Use DBI' statement was not needed, so commenting it out fixed the problem. But I would have been in big trouble if I had actually coded in DBI.
Unless one has control over one's target environment or is reasonably certain about what it will be the less fancy modules used the better.
| [reply] [Watch: Dir/Any] |
|
I can't agree with that. Modules are there to make your
life easier by reusing code as much as possible.
If you can't get your client/boss/ISP/whatever to install
whatever modules you need then you should seriously consider
getting a new client/boss/ISP/whatever.
--
<http://www.dave.org.uk>
European Perl Conference - Sept 22/24 2000, ICA, London
<http://www.yapc.org/Europe/>
| [reply] [Watch: Dir/Any] |
|
That's just a problem with your infrastructure and machine builds nothing to do with the suitability of DBI
| [reply] [Watch: Dir/Any] |
|
So, if you didn't use DBI how do you intend to communicate with your database? Talk to the DB directly via sockets?!
I do agree with trying to simplify things if you don't have control over the environment, but your example is buggy. Also, why not install the modules required locally within the area you do have control over?
Sigh...
| [reply] [Watch: Dir/Any] |