I’ve just finished the mod_perl Developer’s Cookbook. Excellent. Truly excellent. This is the book that I wish I had when I started into mod_perl. The Eagle Book is essential but was a bit much for me the first time I read through it. Now that I’ve been working with mod_perl awhile, and especially now that some things have been clarified for me by reading the mod_perl Cookbook, I feel that I can tackle the Eagle Book again and get a whole lot more out of it. With all the handy and well-explained examples in the Cookbook, many of which show how to do things I’ve been wondering about for a long time, I feel ready to tackle some of the tougher projects that I’ve let languish. I have so many, many ideas for things that I want to tackle with mod_perl.

What’s so special about mod_perl, you ask? For starters, and I admit that this was what sparked my first interest in it, it embeds a perl interpreter in the Apache server, cutting down on the startup time that causes the bottleneck in a CGI environment. But hey, that’s what mod_php does, so maybe you think that’s nothing special. And although important, it’s hardly what I find most exciting about mod_perl. No, the beauty of mod_perl is that it offers hooks into the Apache API: access to the server’s internal processes. The power and flexibility that this affords the developer makes me giddy. And terrified.

Every now and then I find myself in a discussion about the merits of one web server over another (usually IIS vs. Apache). mod_perl is one of the top reasons that I like to use Apache.