At 12:17 PM 5/2/96 -0400, new-httpd@hyperreal.com 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
>them.
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...
-Doug
>
>rst
>
>
|