mod_perl 2.0

geoff on 2002-04-09T14:35:07

so, the new beta of mod_perl 2.0 has been released, alongside the "General Availability" release of Apache 2.0.

in general, I think this is really great - it's nice to see these two technologies make strides forward and (most importantly) entering some sort of API freeze. however, with the next generation of Apache technologies now available, we're starting to see questions like this - basically, now that the 2.0 API is somewhat stabilized, what does that mean for the 1.3 tree?

now, I'm in no position to speak for the ASF as I'm not a member (nor would I speak for them even if I were :) but as someone who authored a (recent) book that is entirely 1.3 centric I thought I'd share my thoughts on what I think this means. after all, even as I was writing my proposal, development on mod_perl 2.0 was underway - I had to be able to justify writing a 1.3 book (most importantly to myself) right?



probably the most sigificant factor for me was that much of the tecniques that have been developed in mod_perl 1.3 won't change - access to the request record is still via $r, most of the API (like Apache::Table) is still pretty much the same, and the basic methodology hasn't changed (you still use a PerlTransHandler to handle URI->file mapping). Furthermore, there's the Apache::compat layer for back compatibility to 1.3 for things like Apache::File, so (after things settle down) just about all of your 1.3 code will run (relatively) unmodified on the 2.0 architecture. kudos to Doug and company for making that happen.

about the only things I can think of that will change significantly is stuff like the current Apache::Filter - output filtering is entirely different and will require quite a learning curve. Also, the custom configuration directive API will change entirely, so the 1.3 model is obsolete in 2.0. The good thing is, though, that the concepts behind these techniques are the same, so what needs to change is the implementation of your code, not the separation of functionality in the architecture you designed under 1.3. so, again, lots of the concepts that have sprung up in the mod_perl community over the years, those that I was trying to present and clarify, will still be valid in the 2.0 architecture.



another thing that I think is important for people to understand is that major architecture changes like this just don't happen overnight - they take years. just look at the latest report from Security Space: nearly 80,000 production boxes are still running Apache 1.2. when I think about the risk involved in ugrading a production grade server I personally get very nervous. How long do you think it would take a company like e-toys (if they still existed) to migrate their architecture? it's not something that you enter into hastily, that's for sure. and in the meanwhile, there are still bugs to fix, enhancements to write, and other things that have to happen to the existing 1.3 code (for which you still need a reference).

all that said, I think that mod_perl 2.0 has some great advantages that people won't find until they start to delve into it. stuff like the threaded MPM might allow for all kinds of interesting behaviors we can't even fathom now. I'm personally the most excited about input filters and the effect that will have on both normal HTTP processing and other protocols as well. really cool stuff, that's for sure. And the code in mod_perl 2.0 is much cleaner now, which should help in both the development and maintenance arenas.



I only wish I had a job that allowed me to play with the new, cool stuff. so far, I'm way behind the learning curve with 2.0, and I had wanted to contribute more on the development front, but the current economic state just seems to make that impossible for me now. but I guess that's ok, something will come up. and in the meanwhile I can still help keep 1.3 humming along, nice and stable, for as long as necessary.