httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From (Doug MacEachern)
Subject Re: mod_perl testing
Date Thu, 02 May 1996 17:58:41 GMT
At 12:17 PM 5/2/96 -0400, wrote:
>A bit of perspective --- there are two ways to view mod_perl.  One of them
>is as a better way of implementing CGI-style functionality.  In this view, the
>usual CGI restrictions are desirable and make sense.  Another is as a Perl
>binding to the API.  Since API code is generally viewed as becoming part of
>the server, able to function without restriction (save only for restrictions
>it allows webmasters to impose on its own function), on that view, it would
>be an design error to make it more restrictive.
>One way out might be to reflect this distinction in mod_perl, allowing people
>to declare both "module-like entities" (which can do anything a C-coded module
>could do) and "script-like entities" --- with, of course, dramatically tighter
>restrictions on who can create the former and where the server would look for

Yes, there two ways to view mod_perl, so far, I've tried to provide both in
mod_perl, perhaps this is the wrong approach.  If you get a chance to look
at the code, you'll see that mod_perl.c is *very* small, most of the code is
in Apache.xs, which provides the Perl->C glue.  
So, another way out might be to have two seperate modules.  mod_perl which
provides a binding that is restricted only as far as the Apache API itself,
and mod_perl_cgi which enforces standard CGI restrictions, sets up the
standard environment, with the only visible difference being speed.  
They would both share the code in Apache.xs, only mod_perl gets to see more...



View raw message