* Adam Turoff ([EMAIL PROTECTED]) [26 Sep 2000 17:15]:
> On Tue, Sep 26, 2000 at 05:02:02PM +1100, iain truskett wrote:
> > Is there much point having a lightweight CGI module? If you say 'I want
> > it to load quickly', I say 'get mod_perl'.
> There's more to it than just loading quickly. It should load quickly
> as in "load everything that's absolutely necessary but nothing more."
> Taint mode is necessary, and half the reason for this proposal.
But is anything else? I like what Nathan Wiger suggested --- that of the
common headers function, but I also believe that belongs as a separate
module. Hence:
#!/usr/bin/perl -wT
use Headers;
use CGI;
my $cgi = new CGI;
my $mail_headers = new Headers;
my $cgi_headers = new Headers;
$cgi_headers->add(
-content-type => 'text/html',
-expires => 'now',
);
$mail_headers->add(
-from => '[EMAIL PROTECTED]',
-to => '[EMAIL PROTECTED]',
-subject => 'Re: RFC 288 (v1) First-Class CGI Support',
);
if(fork())
{
my $email = new Email;
$email->headers($mail_headers);
$email->body = <<EOF;
Note: two separate headers objects which are keeping track of their own
headers rather than messing each other up. Which one gets autoprinted?
Perhaps have a "$cgi_headers = Headers->new->autoprint" type thing.
(i.e. $cgi_headers->autoprint).
Or perhaps: $cgi->autoheader(\$cgi_headers);
I would assume the autoprint would only happen in prints to STDOUT, not
to other things, such as a sendmail process.
And, yes, I know assignment to methods doesn't happen atm, but that's
been RFC'd somewhere iirc (or does 5.6 have that? No matter: not
important. If someone can be bothered to find it, email me privately).
EOF
$email->send;
}
else
{
print $cgi->headers($cgi_headers);
print $cgi->start_html;
.
.
.
}
[...]
> > This would be useful. I'd be more inclined to have it with the CGI
> > module though. But then, it would need to be an option since
> > sometimes programs use CGI bits and pieces but don't run in a CGI
> > context (such as mod_perl scripts, and the odd script I have for
> > generating semi-static documents).
> This has nothing to do with CGI context.
Ah. So, from the view of we mod_perl users, you'd be adding stuff to the
core that would be useless?
> > > Robust input parsing: yes.
> >
> > > General purpose output formatting: no, [...]
> >
> > > Rudimentary HTTP header emission: probably.
> >
> > I think it all belongs in the CGI module really.
> Then you're probably against this proposal. No biggie.
Yeah. I contemplated saying that outright in the previous one but was
having trouble phrasing it in a friendly sense =)
> > The assorted Apache modules (and HTML::Embperl and similar) and the
> > CGI module really do provide proper facilities for CGI operations.
> > Having "rudimentary" features in the core would be duplication and
> > hence a waste.
> Even if the core implementations were so lightweight that they could
> be reused as-is across all the other modules?
Lightweight, but "rudimentary". Typically modules like to provide a
powerful feature that's not lightweight. Hence, they'd have to
reimplement the core implementation if it were lacking. I suspect it
would be easier to make it into a module and reimplement the module
rather than the have a module reimplement core material.
Of course, given the number of perl 5 modules that *do* reimplement core
functions this may not be a problem. The CGI module, for example, could
demand a suitable version of some module that reimplements the given
builtin. Would slow things down a bit more for CGI users, but they'll
cope?
cheers,
--
iain truskett, aka Koschei. <http://eh.org/~koschei/>
You know you are addicted to coffee if...
13 You walk twenty miles on your treadmill before you realize it's
not plugged in.