I haven't actually read the other mod_perl and developer-oriented Apache books out there but in my opinion this book is still indispensable if you plan to write Apache modules, either in Perl, C, or other languages. Especially if you write for mod_perl, this book is a great complement to the mod_perl guide. Stas' guide focuses on deployment and tuning issues (memory usage, speed, etc) while WAM focuses on the Apache API and how Apache can help you do the job by writing modules.

Personally, _Writing Apache Modules_ is still the most useful reference book to date. It's one that spends the largest amount of time on my desk.

And, oh yes, Amazon gives a good deal on this one ... .

Can't wait for the Apache 2 counterpart.

When we do begin the writing of a module, it isn't a basic, stand-alone module, but a module to add footers to other content. So, the text digresses into a long and technical discussion of the various ways to configure Apache and associate MIME types so that this module will work with documents that we might or might not have on hand (It's just assumed that you have these laying around handy). During this discussion, we get bounced off of other Apache::xyz modules that apparently popped into the author's head in a moment of "As long as we're at it, why don't we throw this in too" inspiration. Wonderful information ... presented at the wrong time.

To give an example: A logical place to start learning Oracle SQL (or any other SQL) would be with the SELECT statement. However, the authors of this book would begin with a detailed discussion of PL/SQL exception handling, a listing of most of the built-in PL/SQL exceptions, and a listing of a number of the built-in Oracle packages. (Recall we were just starting with SQL. But what the heck! PL/SQL is cool, so why not talk about it now? We're going to use it eventually anyway.) Then for your first select statement, you would write something that used a complex join, a correlated subquery, and a few built-in functions. Well, obviously, we can't just throw this extra stuff in there and not talk about it. So we go whirling off into a discussion of complex joins, correlated subqueries and any other tangents that happen to pop into our head. And when it is all said and done, we still don't know how to display the entire contents of the EMP table.

This is a classic of case of making it difficult to see the forrest because of all the trees. The authors of this book have made no attempt to devise a progressive model for building knowledge. Instead, information is dumped on the reader apparently in the order it came to mind. Maybe this is a problem with having multiple authors. Perhaps the parts were written independently, then slung together. That's what it looks like.

I suppose this book will get you to where you are going ... eventually. But I suspect you will spend considerable time flipping back and forth between chapters re-reading and re-re-reading sections in order to re-assemble the information in a somewhat logical pattern; hence the comparison to a 5,000 piece puzzle.

For those who might be wondering: This book assumes you already know the Perl language. If you don't, the "Learning Perl" book is a good starting point (you do NOT want "Programming Perl" at this point). You will probably also want to get some knowledge of HTML and building web documents. And you will probably want to get at least a basic knowledge of custom configuring an Apache installation.

The first part of that truism can perhaps be said of Web Wizards and Apache modules. Fortunately Apache modules are a little easier to write than Sendmail configurations and this book makes it easier still.

Let's not mince words. Perl scripts and other CGI software can quickly become performance bottlenecks on any server, no matter the size of your hardware. The most powerful way of fixing this is to fold a fair amount of that programming inside the server where the overhead of loading interpreters, libraries and code is already taken care of, not to mention you find yourself with much more power and control over the dialogue between server and browser.

Unfortunately writing to an API as large and complex as that in Apache is not always easy. MacEachern and Stein go to a great deal of trouble and exert a fair degree of skill in breaking the learning down into manageable chunks and explaining it all with a large number of examples.

This was the first book I read that really made me understand the process going on, both between the two pieces of software and inside Apache, when a page is requested. From there the book goes on to give you a marvellous understanding of how to write a module in Perl that fits into that process. Finally the last three chapters are excellent API reference guides, one on the Perl API and two on the C API, and an excellent index (which indexes every function in the API's as well as key concepts) make this a superb tool when you get down to writing.

The book does not cover using C in any where near as much depth, but the vital conceptual understanding required and explained in the Perl chapters means that once you have written a module in Perl I don't believe you will find it a problem to do it in C. I have to say though, as a C programmer I am yet to do it, I get so much performance out of a module in Perl I've yet to find the need.

I read this book before starting my first module and I have now written three. I would never have even contemplated the task before reading this volume. I would recommend this book to anyone who wants to get a full understanding of writing software for the web and anyone who wants a quantum leap in the performance of their web software. You will need some fair Perl skills and preferably written a few CGI scripts as this book does not cover the language skills required at all.

In addition, the book provides insights into the world of web servers and HTTP, examples of real problems and how they can be solved and first class examples of readable yet succint Perl code.

I would recommend reading Randal Schwarz's Perl columns in for more real world applications.