Recently I've been experimenting with writing an Apache module, mostly to get a deeper understanding of how the server works. I've been intrigued by the concept of the APR portable runtime for a while, and with the recent release of Apache 2.2 and some of its more interesting features (like the Event MPM and the mod_dbd database manager), now seemed as good a time as any for a little exploration.
Writing modules in C can be hard, not so much because C is an intrinsically more difficult language to use but rather because there aren't as many cohesive, readily accessible libraries and frameworks available for modern Web 2.0-ish development. That means if I'm ever to have any hope of getting real applications written, I'll need to fall back on my trusty Ruby on Rails.
Running Rails means FastCGI. And so I download the FastCGI developer kit and install it on my server. No problems so far. Then I download mod_fastcgi to let Apache communicate with my Rails apps and...it won't even compile. It seems that this module hasn't been updated in a number of years. It works well enough with Apache 1.3. You can get it to run with Apache 2.0, although at the office we downgraded back to the older server after experiencing occassional unexplained problems. The support for Apache 2.0, it seems, relied on some compatability code to mask some of the rather substantial changes in the API. This compatability layer, however, was removed in the Apache 2.2 release and so the module no longer works at all.
There's an alternative module: mod_fcgid. I grabbed the source and was able to compile the module! After fussing around with build tools for a while (it seems the GNU libtools applications were installede without shared object support) I got the module built and installed. Unfortunately, bringing up the web server is rewarded with an immediate crash. After looking around on the web for a while, I discovered that the solution was to go back two releases of the module and then patch the code to supply a missing header file. Finally I was able to bring the server online, but by that time I was ready to fall asleep, too tired to see if I could actually invoke a FastCGI script.
Is this any kind of indication of the quality of open source software???
I suppose I could switch to using Lighttpd as my web server, which does come with a functional FastCGI interface. But then I wouldn't have access to Apache for my other experiments or for things like installing a Subversion source code repository.
The popular solution to this dilemma seems to be to configure Apache to run as a proxy in front of Lighttpd. But why would I want to do that? In addition to the extra performance overhead and increased risk of failure due to the increasingly complex number of moving parts, doesn't this just subject me to all of the weaknesses of both products?
