It's unclear to me, though, that there are unimaginably
cool things you can get to in a "real" content handler that you can't get
to from an Apache::Registry script--which seems to be the assertion.
well, if you consider that you still get access to $r and all its treasures from Apache::Registry, then that's mostly true.
> I > mean, even from the "lowest common denominator" CGI you can get all parts > of the incoming HTTP request, plus output arbitrary headers.
it's when you use Apache::Registry as a wrapper for your legacy CGI scripts that the difference really begins to show. consider something like this
http://www.perl.com/pub/a/2002/02/20/css.html
while most templating systems don't have this issue with HTML entities, using the mod_perl API gives you ways of handling tasks like CSS protection behind the scenes. and I think that's unimaginably cool.
other cool stuff comes at the end of this talk,
http://www.modperlcookbook.org/~geoff/slides/ApacheCon/2002/oo-mod_perl-printable.ppt.gz
which touches on Apache::Registry-as-legacy-CGI-wrapper limitations
see also
http://www.modperlcookbook.org/~geoff/modules/experimental/Apache-CachePOSTRegistry-0.01.tar.gz
which handles the issue of merging legacy CGI Registry scripts with POST data issues
and
http://www.modperlcookbook.org/~geoff/modules/experimental/Apache-HEADRegistry-0.01.tar.gz
which addresses the fact that Registry does not properly handle HEAD requests.
given all of that but not wanting to speak for anyone else, I think that once you buy into the-mod_perl-API-is-better approach, there are really few reasons to use Registry over content handlers, as Registry adds an additional but unnecessary level of complexity and indirection.
--Geoff
