small project / experiment to learn mod_perl

[Anonymous Monk]

Can anybody please suggest me a small experiment or project by which i will be able to better learn / understand mod_perl.

Am a perl programmer for past 5 years. By googling i found mod_perl is very similar as perl. I have to spend time only in knowing about the mod_perl APIs, and nothing more.

If somebody asks me, I know programming, i would like to learn perl programming by experimentation, i will say take this log file ( may be syslog ), and produce reports like, word count, all ERROR lines and major errors, timing based report by giving command line option, print particular hours log lines. So this way he will be able to understand both data structures & regex in Perl.

I am expecting something similar or more better, experiment details, which i will do by my own & learn mod_perl.

Thanks for your time.

[bluescreen]

I'm a web-programmer and my advice is that you spend more time learning Plack/PSGI than Mod_Perl. Plack/PSGI is really cool and only couple years old only (not mainstream yet but I think it'll be). It allows you to isolate your code from the webserver + interface, so then your code runs in multiple webservers ( Apache 1.3, 2.2, Starman, Nginx, ... ) with multiple interfaces ( FastCGI, mod_perl, CGI, ... ).

[sundialsvc4]

I’ll second (or third, or fourth ...) that opinion:   mod_perl is not the thing to use; FastCGI is better, and (from a flexibility and compatibility standpoint), the Plack/PSGI layer is better still.

The main reason why I say that, and my motivation for now being in the process of converting an app away from mod_perl, can be summed up very simply:   Pads and Phones.   These interfaces aren’t going to be using HTTP web-servers anyway.   It’s quite impossible to predict who the winners will be, and how many winners there will be.   (Hell, they might be expecting to use our apps on their personal holodecks within five years, for all we know ...)   So, applications need to be loosely coupled to the interface server(s) that drive them.   mod_perl is emphatically not that way.

(Stepping quickly to mod_perl’s defense, there is no doubt that the tool was carefully and lovingly crafted to be precisely what it is, and that, under the then-prevailing engineering conditions, it might well have been the cat’s meow.   It was, and is, a fine piece of software engineering.)

An app that’s written for mod_perl (without the use of a compatibility layer like PSGI) is literally “wedded at the hip to” ... Apache.   It is “wedded” with the additional and very-significant cost that it makes the httpd processes large and unwieldy ... which they were never intended to be.   It also makes those processes singularly responsible for anything and for everything that the web-site user may wish to do.   This is far too much, and far too “tight,” coupling ... not only to a particular delivery model, but to a particular delivery server.

At this point, “hardware is cheap.”   I can literally order a new cloud-server and have it at my beck and call in about twenty minutes.   For a few thousand a month, I can have quite a little “farm” of them.   That didn’t used to be the case.   Now, the most-natural processing model is a highly-distributed one, and my natural predilection is going to be, “throw silicon at it.”   I need to be able to build nimble, multi-tier application (servers) that distribute work efficiently and that support many public-facing APIs, including those not yet contemplated.

[John M. Dlugosz]

I think there are two issues here. I agree that going with an abstract standard is better than going with a specific product, when learning the API to write your code with.

In my case, I eventually needed to choose a specific product to install, so I had to figure out not the API but how to configure it and get my app running.

So if you learn to write against PSGI and write your application, then you still have the chore of choosing several specific products and getting it all running.

[Anonymous Monk]

Absolutely correct.   The difficulties arise when you find that you must change the method of deployment, or even when you find that your app must support more than one method of deployment simultaneously.   These are realities that are now facing us with regard to both our new and our already-installed applications.   Yes, as you say, we still have to make the technical moves.   Nowadays we have a very compelling need not to be boxed-in to the moves that we have chosen to make ... no matter for what then-good reasons we made them.   On both the client side and the server side, “the games, they are a changin’.”

[roboticus]

What I normally do for improving my skills with a tool is to use it to write something that I'll find useful. I'm fairly picky about tools, so rather than use standard ones that everyone uses, I frequently write my own. Since I do database stuff quite a bit, I typically write little database whacking tools. I've got an SQL query tool that I use that does a few things that none of the commercially-available ones do. (Of course, since it's my own tool, and I don't care about the appearance, it's quite ugly.)

Since you're wanting to do some web stuff, and you mention log files, perhaps you should write a nice web log analyzer with a web front end. Or perhaps a systems monitoring page that you can use as your home page. Just pick an itch, and scratch it!

...roboticus

When your only tool is a hammer, all problems look like your thumb.

[John M. Dlugosz]

When I did a recent web project, I found out that mod_perl is not recommended, and fastCGI should be used instead.

I just saw another post, few days ago, where someone mentioned learning mod_perl only to discover its deprecated status after putting several days into it.

[Arunbear]

There are a lot of companies that still use mod_perl, so learning it is not a waste of time.

[fishy]

Hi Monk, I'm on the same road.
I bought a copy of "mod_perl 2 User's Guide", set up two virtual machines with a basic Debian system and compiled mod_perl into httpd.
My aim is playing around with a kind of distributed system, letting the machines talk over http to each other.