porting mod_perl content handler to CGI
Howdy,
I have an application that's pure mod_perl -- its modules use the request
object to do a few bits of work like reading parameters, query string,
specialized logging, dealing with NOT_MODIFIED, and so on. Normal stuff
provided by the methods of Apache, Apache::Util, Apache::URI and
Apache::Connection.
Now, I'd like to use a few of my modules under CGI -- for an administration
part of the application that's bigger and not used enough to use up space
in the mod_perl server. But it would be nice to have a common code base.
So, I'm writing a replacement module of those classes and supporting just
the few methods I need. I'm using CGI.pm, URI, HTTP::Date and so on to
handle those few mod_perl methods I'm using in my modules.
For example, I have a function that does specialized logging that I want to
use both under mod_perl and CGI. So, this would work under CGI
my $r = Apache-request;
my $remote = $r-connection-remote_ip;
where in the replacement package Apache::Connection:
sub remote_ip { $ENV{REMOTE_ADDR} }
Before I spend much time, has this already been done?
Might be kind of cool if one could get new CGI programmers to write all
their CGI applications like mod_perl handlers -- could run as CGI on other
servers, but when they want speed they are ready to use mod_perl.
Anyway, does a mod_perl emulator for CGI exist?
Bill Moseley
mailto:[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: porting mod_perl content handler to CGI
On Fri, Nov 17, 2000 at 11:53:05AM -0800, Bill Moseley wrote: Now, I'd like to use a few of my modules under CGI -- for an administration part of the application that's bigger and not used enough to use up space in the mod_perl server. But it would be nice to have a common code base. One possibility is to require My::Memory::Hog ; once you know it needs to be used, then to suicide your process when done with the request. That's not always a good idea, if your childinit takes a long time, for instance, but it may simplify your life to not have to worry about the two different environments. Before I spend much time, has this already been done? I do exactly this for a largish chunk of code, I have a Safari::Request object that I fill in from a comand-line or CGI script. You might also look at Apache::FakeRequest. I can send you mine (I posted it to this list or another list recently). There is definitely a recurring interest in runnng mod_perl scripts from command line and via CGI. That's not feasible for all scripts, but for the more "plain vanilla" ones, it should be. - Barrie - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: porting mod_perl content handler to CGI
Bill Moseley wrote: Howdy, I have an application that's pure mod_perl -- its modules use the request object to do a few bits of work like reading parameters, query string, specialized logging, dealing with NOT_MODIFIED, and so on. Normal stuff provided by the methods of Apache, Apache::Util, Apache::URI and Apache::Connection. Now, I'd like to use a few of my modules under CGI -- for an administration part of the application that's bigger and not used enough to use up space in the mod_perl server. But it would be nice to have a common code base. I have the stub of one I developed for Apache::ASP called Apache::ASP::CGI. I got it to the point that I could run ASP scripts from the command line, but not much farther. I was able to get scripts to run under CGI, but as I recall, I never implemented POST reading very well. If you would like to roll this into a CGI::Apache or Apache::CGI, that would be great. You can find this package in the body of the ASP.pm module. --Joshua - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
