With the 2.0.35 "General Availability" release of Apache 2.0 in early April 2002,
and the beta release of the newly redesigned mod_perl 2.0 to match,
there may be some concern as to how applicable our book will be to your
everyday development efforts. This concern is understandable, and we hope
here to present some of the issues so you can decide if our book is
right for you. We think that it is, but read on if you need just a bit
The mod_perl Developer's Cookbook is entirely focused on the
Apache 1.3 architecture, for which mod_perl (currently 1.26) was
designed. Part of the reason for this is that neither the Apache 2.0
nor the mod_perl 2.0 API had been solidified while we were writing -
at the time, both APIs were moving targets and the mod_perl 2.0 was
being constantly changed and tweaked as Apache 2.0 was taking shape.
Of course, both Apache 2.0 and mod_perl 2.0 are in much better shape
now, fairly stable and, in mod_perl's case, ready for people to
start tinkering. The good news is that our book can help you do
that, even though it is focused on the Apache 1.3 architecture.
One reason the mod_perl Developer's Cookbook can help
is that many of the underlying concepts for the Apache 2.0 architecture
are the same as 1.3. For instance, the request cycle is pretty much the
same, still offering hooks into phases like URI translation, resource control,
fixups, and content generation. There are still mechanisms for
subrequests and lookups, handlers still return constants like
DECLINED, and major structures
like the request record still hold the same information. Since the
goal for mod_perl 2.0 is the same as mod_perl for the 1.3 tree --
to provide access to the Apache API through Perl -- the methodology
used to develop mod_perl applications for the 2.0 architecture
is nearly the same as it was before.
We think you will find that the mod_perl Developer's Cookbook
provides insight into these various topics that you will not
find elsewhere, and will help strengthen your understanding of
both mod_perl and Apache as you develop for either the 1.3 or 2.0
Although some parts of the API are not the same, mod_perl
2.0 provides the
Apache::compat compatibility layer.
So, with very little work, you should be able to get your 1.3 code
(and most of the code from our book) working with mod_perl 2.0.
We have to admit, though, that some of our examples push the
envelope to the limit and most likely will not be directly
portable to mod_perl 2.0. But these examples really exist to
get your mind moving in all sorts of new directions and show
what types of things you can do once you understand what
access to the Apache API in Perl really means.
With any new implementation, though, there are inevitably
old features that have been deprecated and new features that
are non-existent in the old design. For mod_perl the most
notable of these is the introduction of filters into the
Apache API, which will make techniques like
obsolete under mod_perl 2.0. Another area that will be
different is the creation and use of custom configuration
directives, which is much simpler and does not require XS.
The good thing is that the concepts behind these techniques, and other
areas where the two architectures differ, are sound development
techniques regardless of the particular version of the Apache
API you are implementing.
All that aside, the main reason you may still be interested in picking up
the mod_perl Developer's Cookbook is that mod_perl for
Apache 1.3 will be significant for a very long time - as you think
about migrating your application to mod_perl 2.0 there are
still bugs to fix, enhancements to implement, and other things
to be done to your existing production code for which you still
need a reference.
We think that our work, being the first significant
book on mod_perl in nearly four years, can teach you lots of
techniques you never considered and take you places you never
would have investigated, each of which will make you a better
mod_perl developer in the end.