httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom Tromey <tro...@cygnus.com>
Subject Re: mod_perl testing
Date Thu, 02 May 1996 17:05:48 GMT
Robert> One way out might be to reflect this distinction in mod_perl,
Robert> allowing people to declare both "module-like entities" (which
Robert> can do anything a C-coded module could do) and "script-like
Robert> entities" --- with, of course, dramatically tighter
Robert> restrictions on who can create the former and where the server
Robert> would look for them.

I think there are actually (at least!) 3 ways one would want to use
Perl (or any embededded language):

1. As an interface to the API, that is, a module
2. As a faster CGI.
3. As an interpreted server-side include

For items #2 and #3, the code must be interpreted in some sort of safe
compartment (Perl terminology -- Tcl has a similar notion).  As a
webmaster you would like to open capabilities such as #3 up to your
users, without sacrificing security.  Safe compartments are the way to
go here.

But a module written in Perl should have no such restrictions -- only
the web admin should be able to install such code.

Not everyone will want all 3 capabilities.  I'd ask that the mod_perl
author(s) try to separate embedding Perl from the particular features
of their module (which as I understand implements #1?), so that the
others can be implemented as optional modules on top of the embedding.

I'd also like to see mod_include extended so that an add-on can easily
register a new include type (ie "perl" or "tcl").  Maybe I'll do this
someday, we'll see.

Tom

Mime
View raw message