RE: Apache::Request for CGI? (was: Re: A::Registry vs. mod_perl handler philosophy)

["Philippe M. Chiasson" <go...@cpan.org>]

On Wed, 2003-07-02 at 22:36, Jesse Erlbaum wrote:
> Hi Joe --
> 
> > +1.  Scripting _inside_ the server opens up possibilities that
> > are unimaginable to folks who are content confining themselves 
> > to the lowest common denominator (CGI).
> 
> Perhaps you could bullet-point a few of these possibilities for those of
> us who are confined by our lack of imagination?

Check out the guide:

http://perl.apache.org/guide/

Check out the books:

http://perl.apache.org/docs/offsite/books.html

Check out the success stories:

http://perl.apache.org/outstanding/success_stories/index.html

> 
> TTYL,
> 
> -Jesse-
> 
> 
> --
> 
>   Jesse Erlbaum
>   The Erlbaum Group
>   jesse@erlbaum.net
>   Phone: 212-684-6161
>   Fax: 212-684-6226
> 
> 
> 
> 

Re: Apache::Request for CGI? (was: Re: A::Registry vs. mod_perlhandler philosophy)

[Perrin Harkins <pe...@elem.com>]

On Wed, 2003-07-02 at 20:38, Andrew Ho wrote:
> I totally agree with the fact that Apache::Registry can introduce many
> hard-to-debug-problems. I've had enough headaches debugging some of these
> issues myself. 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

I would phrase it differently and say that there are nice things you can
do when you embrace the fact that you're in a persistent environment. 
You can do a lot of things in ways that are compatible with both CGI and
mod_perl, by checking the environment and acting appropriately, but it
can be a pain when you want to take advantage of cleanup handlers,
preloaded data, persistent connections, etc.

You can do all this from A::R, but once you've decided to write
something that is not going to work under CGI I can't see any reason to
use A::R anymore.  At that point, it's just an artificial construct that
adds complexity to your system.

> I have found that often the Apache::Registry functionality of not having
> to restart servers when simple scripts change is worth the potential of
> bugs tickled by the Apache::Registry sub-wrap approach.

People often say this.  I just don't see it.  Apache::Reload works just
as well.  My dev server restarts in about a second, so I always restart
it when I make a change just to feel confident that I'm not seeing any
residual effects from previous code.  The whole reload thing is not
perfect anyway, and people have had problems with A::R's reload when
working with code that has closures in it. 

My opinion is that you should use A::R if you need CGI (or SpeedyCGI,
etc.) compatibility, but use handlers otherwise.

- Perrin

Re: Apache::Request for CGI? (was: Re: A::Registry vs. mod_perlhandler philosophy)

[Geoffrey Young <ge...@modperlcookbook.org>]

> 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

Re: Apache::Request for CGI? (was: Re: A::Registry vs. mod_perlhandler philosophy)

[Andrew Ho <an...@tellme.com>]

Hello,

GY>mod_perl allows you to let your content handlers to focus on content -
GY>all other parts of your application (authentication, session management,
GY>proxying, URL rewriting tricks, etc) can programmed at the server level
GY>via other parts of the request cycle.

I think the question isn't "why is Apache::Registry not sufficient to
handle all functions within an HTTP request" but "why is it bad to use
Apache::Request specifically for the content generation phase?" Perrin had
some good practical reasons for this--caused by the generated-namespace,
sub-wrapped, eval'ed nature of Apache::Registry. 

I totally agree with the fact that Apache::Registry can introduce many
hard-to-debug-problems. I've had enough headaches debugging some of these
issues myself. 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. I
mean, even from the "lowest common denominator" CGI you can get all parts
of the incoming HTTP request, plus output arbitrary headers.

I have found that often the Apache::Registry functionality of not having
to restart servers when simple scripts change is worth the potential of
bugs tickled by the Apache::Registry sub-wrap approach. I think it's a
fine tool for simple content generation scripts and that it doesn't limit 
you at all in that aspect.

Humbly,

Andrew

----------------------------------------------------------------------
Andrew Ho               http://www.tellme.com/       andrew@tellme.com
Engineer                    1-800-555-TELL          Voice 650-930-9062
Tellme Networks, Inc.                                 Fax 650-930-9101
----------------------------------------------------------------------

Re: Apache::Request for CGI? (was: Re: A::Registry vs. mod_perlhandler philosophy)

[Geoffrey Young <ge...@modperlcookbook.org>]

Jesse Erlbaum wrote:
> Philippe --
> 
> 
>>Check out the guide:
>>Check out the books:
>>Check out the success stories:
> 
> 
> Is that your answer?  I was hoping for specific examples, not
> hand-waving.

I like to think that Part III (Chapters 11-17) of the mod_perl Developer's 
Cookbook does some of that.

authentication is a good example of how mod_perl enables life outside of CGI 
scripting.  if you require authentication in your application, auth handlers 
allow you to entirely remove authentication from your content handlers.

mod_perl allows you to let your content handlers to focus on content - all 
other parts of your application (authentication, session management, 
proxying, URL rewriting tricks, etc) can programmed at the server level via 
other parts of the request cycle.

I'm talking about this at a very basic level at OSCon this year (as I did 
last year), but you might be interested in my slides from YAPC2002 to get a 
general feel for it (and ApacheCon if you want to see the more twisted side 
of what mod_perl opens up).

http://www.modperlcookbook.org/~geoff/slides/

HTH

--Geoff

RE: Apache::Request for CGI? (was: Re: A::Registry vs. mod_perlhandler philosophy)

[Jesse Erlbaum <je...@erlbaum.net>]

Philippe --

> Check out the guide:
> Check out the books:
> Check out the success stories:

Is that your answer?  I was hoping for specific examples, not
hand-waving.

-Jesse-


--

  Jesse Erlbaum
  The Erlbaum Group
  jesse@erlbaum.net
  Phone: 212-684-6161
  Fax: 212-684-6226