Just as one may write an application acting as if there were only only database, one could do the same for CGI frameworks and only use mod_perl. However, this is unfair to those on other OSes or platforms.

• Performance. Everyone knows about this one: the Perl interpreter is embedded in the server process, the scripts are compiled only once. No forking and recompiling at every request.
• Access to all request phases. CGI is limited to the content delivery phase. mod_perl lets you write your own authentication handlers, access handlers, logging, whatnot. One very useful handler is the translation handler, which lets you determine how you will serve the content at runtime, as opposed to a static configuration.
• mod_perl exposes the Apache API, whereas mod_cgi only offers a handful of environmental variables. Escape URIs and encode HTML faster than those pure Perl modules from CPAN. Issue subrequests to do your own SSI-like thing. Many possibilities, the Apache API is very rich.

I don't understand why it should be unfair to other OSes or platforms? Apache runs on every OS/platform one wants it to run on - at least on those which can be considered as useful OSes/platforms for running a webserver at all. So I don't get it what's unfair there. That's just a bogus reason for people who really mean IIS and not OS/platform.

Personally I even go further: I use HTML::Mason which is the greatest thing I've ever seen for website programming. I don't really know how argument handling is handled in pure mod_perl, but HTML::Mason makes it really save - one of the things cgi scripts usually are accused for. It also lets you template your site with splitting design completely and cache different components you are using for differnet times. Also session management is quite easy - just give it a try, look at http://www.masonhq.com/. Of course you can use CGI::Portable within HTML::Mason for your things, it's perl, after all.
--
use signature; signature(" So long\nAlfie");

First, about fairness. I don't think it would be unfair to very many people on "other" OSes because Apache runs at least on Unixes, Windows, and Macs. Anyway, those few platforms not supporting Apache are likely to be less suitable for running a web server. Also, I doubt that those who develop for, say, aolserver are that concerned about compatibility with Apache, so it's not really a fairness issue, IMHO.

I think it's about smartness. You should pick the most suitable platform up front, for your definition of suitable, then go from there. One of the coolest things about Apache is mod_perl. Having perl embedded into the server and the ability to access all the server API is cool. You could argue that aolserver has the same thing with Tcl, but who really wants to program in Tcl? ("Will dis Tcl for XP" the T-shirt would say :) (I don't know what the alternative is with ISS, but I've heard of ISAPI, so there obviously is some way to access their native API. In any case, you'll still be tied down to that platform's API) Also, if you prefer Java over Perl, you can still go with Apache because you have Java servlets, which are the equivalent of mod_perl but using Java.

Probably what it comes down to are things like: can you find/afford developers who know your platform, who know your programming language, can you convince management to use this platform? Platform including language and hardware, not only the http server.

Still, I have to wonder about a DBI-like wrapper around all HTTP servers. Maybe it's a nice idea. But, what language do you write the wrapper for, Perl? What if this Java thing really takes off, maybe you should've written your applications in Java so you could find cheaper developers. Then what good would programming for the generic http API have done?

(Like you, I'm obviously just giving some ideas to consider. Maybe they're not the best ones.)

Professionally (meaning that they pay me, not that my code looks professional) I've tended to not to install it, because they tend to be shared hosting systems, system load doesn't tend to be a problem, and most users wouldn't touch it. The caveats about how you can do a fairly good job of locking up apache with it, if you do things incorrectly didn't make it seem a good candidate.

OTOH I recently came across the sort of thing which mod_perl is ideally suited to - basically a high-traffic server where every hit requires a database hit. By caching the script (for 99% of hits were on that one object) and more importantly, by not having to set up and tear down a DB connection millions of times a day teh efficiency gains are tremendous. The server simply couldn't cope running apache and mysql on top of the rest of its functions without mod_perl, whereas with the script modified to use it, there's plenty of headroom. The clock ticks saved by not having the setup costs for each hit meant that each request finished faster, keeping the number of apache and mysql threads down, gaining more efficiency from that.

the hatter

mod_perl is it's own platform. It has some backwards compatibility code for CGI's, but it is much more than just a CGI framework. It's architecture and basic assumptions are quite a bit different from CGI's - in fact non-trivial CGI applications tend to break if you run them under mod_perl (lifespans of variables are quite different).

Likewise, mod_perl lets you do a lot of things that you just can't do under CGI. Cached database connections being the first to come to mind.

And if you really want something revolutionary, combine mod_perl with HTML::Embperl. Gets rid of all those nasty print()'s and gives a better separation of logic from presentation.

Greetings,

...
in fact non-trivial CGI applications tend to break if you
run them under mod_perl (lifespans of variables are quite different).
...

As the developer of a non-trivial CGI/mod_perl app, I beg to disagree. Aside from a few traps due to the way Apache::Registry namespaces compiled scripts - and which are easily avoided by a sane use of modules - I find that properly coded CGI does live a comfortable life under mod_perl.

I suspect that your observation (as the one below about CGI being of no use in the real world) stem mostly from the unfortunate fact that so many CGI apps are sorry, crappy pieces of code assembled by not very experienced programmers working from cut & paste and hearsay.


Cheers,
alf

---

You can't have everything: where would you put it?

Yes, if you write your CGI with discipline, you can certainly get it to run unchanged under mod_perl. On the other hand, I've made the same observation about the CGI apps I've downloaded. Lots of people leave out the my's, skip the use strict;, and generally do things in a sloppy manner.

I'm sure I'll eventually download one and have it run under mod_perl without problems. But it's usually easier to just enable mod_cgi rather than debugging someone else's script.

As for developing from scratch, well, "limiting" myself to apache/mod_perl doesn't seem to be that big a loss.

YMMV, of course.

I'd be curious what you mean by "Aside from a few traps due to the way Apache::Registry namespaces compiled scripts". Are you referring to the way it treats modules with the same name found in different places in the directory structure as the same module? Quite a headache when you have 3 developers using the same webserver to work on the same app - 2 want the stable version of a module, 1 wants the version he's hacking on at the moment.

I've had trouble while debugging with mod_perl not picking up changes to modules without a webserver bounce (or setting MaxRequestsPerChild to 1). A couple of my coworkers actually have a

* * * * *    /usr/local/apache/bin/apachectl restart

cron job to work around this on their dev boxes.

ED

Other people reactions sum it up for me: speed, flexibility, Apache apis...
Except the last 2 are (I feel) liabilities for people which need to keep IIS and other webservers in view. So I write orderly CGI stuff that runs under mod_perl but will do its thing (if slowly) under IIS with vanilla CGI (and that's already nontrivial).

As for cross-platformness of Apache and friends - it is there, but only to a point. I have been recently badly bitten on the a... - well, you get the idea - by mod_perl being single threaded on Win32 - a fact that is very carefully buried under a ton and a half of carpets. Because I write to CGI.pm I narrowly escaped disaster - had I gone the full mod_perl way it would have been a very nasty situation.

Cheers,
alf

I wouldn't say that mod_perl being single-threaded on NT is "buried". It's frequently discussed on the mailing list. The mod_perl documentation describes the Win32 support as "alpha". If it isn't prominently displayed in the documentation, it's probably because NT support is fairly new, and most of us don't expect anyone doing serious performance-oriented mod_perl work to be working on Win32. You could submit a documentation patch to warn people about it if you think it comes as a big surprise to people.

Ie, can you get at more environmental variables such as the HTTP_REFERER or something?

One thing is you can use $r->pnotes() to pass information from module to module (along the Apache request loop), so there's the possibility of customizing output based on the authorization phase, say, not to mention the ability in the first place to even intervene in the authorization phase. Also, you can cache some data for all requests to use (CGI programs are one-shot deals, so they have to be reloaded every request).

Look at it as a perl developer that is charged with development of web applications. You could use CGI, but you will find very soon that this is to no use in real world. What else should you use? If you are apache user, mod_perl comes to mind as a natural solution.

That worked for me. But I was still looking for some portale, standard-based environment to do full-featured web applications. Found several 'application frameworks' and was not satisfied with any of them. None of them (2 years ago) supported XML, none was component-based. So I began step by step development of my own just-another-perl-application-framework in mod_perl.

Java has JSP, EJB, JA*, etc. Perl has nothing that should work as a standard that a novice should look on, except for old-and-bad CGI.

So, do not be too surprised to find that people take server-dependent systems as a 'standard'.

mod_perl allows for programmatic control of all phases of the request cycle for the popular Apache webserver...

Or put another way ... mod_perl exposes the the Apache Webserver API to Perl and thus exposing the API to the Perl Programmer.

This has always suggested to me a much more powerful flexible way of extending apache functionality than just a backend transaction handler (CGI). The trick has always been to step outside of the 'CGI BOX' by asking ourselves how can I extend the server to do what I want. This is in fact the approach with newer server technologies like 'Tomcat' take.

The problem with mod_perl in my view is that it has never been 'formally' exploited. It solved one big problem almost from its birth: run CGIs faster and then got pidgeoned holed. It is easier just to write mod_perl friendly CGI's then delve deeper into designing and implementing trans_handlers and such. The deeper more interesting ways of using mod_perl, after some initial interest, never got persued. PHP exploited this lack of interest and snuck right up the middle or should I say 'right up the apache request cycle'.

But I am still using mod_perl but not exclusivley, recently our projects have begged for other solutions as the need for more specialized servers continues to grow. As usual princepawn in his special way has got me headed towards another head space minefield. What we really need is a formal structure in which to create Perl extendible 'Application Servers'. There I said it the 'A' word. Are you happy now princepawn.

mitd-Made in the Dark
'My favourite colour appears to be grey.'

I can't see why anyone would use that. You get the complexity of mod_perl with the bad performance of CGI? Maybe you could run your Apache::Emulator script in Apache::Registry or Apache::PerlRun just to complete the circle from mod_perl syntax to CGI-ness back to mod_perl? :)

In the Description section from the link you gave, he points out that some things, like subrequests, are impossible. So that comes back to your question of what parts of application programming are available in mod_perl that aren't in CGI. You can emulate the CGI-compatible parts in mod_perl. The only reason not to just use CGI then would be so that it could run fast if you got to run your stuff under mod_perl. But if that's the case, I think it's just as well to use Apache::Registry and not worry about it. Unless you're in a Tantalus situation where you can't use a real development environment.