* 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.

Reply via email to