> > Parse the CGI context, returning CGI variables into %CGI
> Which variables are you talking about? Everything you need is already in
> %ENV, as I'm sure you're aware.

Yeah, but its encoded... %CGI in an unencoded form would be a nice
thing. :)

> If you're talking about splitting up the query string, then this should
> be stated explicitly. And I think %CGI is a fine place for this. Will it
> be quotemeta'ed?

It should theoretically do the full decode of the CGI environment...
Quotes, etc. included.

> > Offer simple functions to set HTTP headers (e.g. content type,
> result codes)
>
> How about %HTTP, which is just flushed on the first line of output?
>
>    use cgi;
>    $HTTP{'Content-type'} = 'text/html';
>    print "Hello!";     # flushes %HTTP first

Ooo... I like this :) The number of times I've had to construct 3 copies
of the header to cope with bizarre error conditions... Wouldn't it be nice
to:

use cgi;
$HTTP('Content-type') = 'text/html';
#
# other code here including a dup of STDERR to STDOUT
# or perhaps the die can be made to go to STDOUT for CGI
# apps... Hell, its better than a Error 500... ;)
#

open FH, "/etc/imafile" or die "Unable to open file";

prints to STDOUT:

Content-Type: text/html

Unable to open file

or something like that... It would be a nice thing ;)

> Just one idea. Another is to just take the functions out of CGI.pm, but
> then perhaps just using CGI_Lite is a better alternative.

Never used CGI_Lite... Why would a cut down version be better?

> The RFC should just be a little more specific on what's being included
> and not included. Are any of the functions like header(), h2(),
> footer()? What about %ENV manipulation functions? What do people think?

I think that the current CGI module functionality should perhaps be
maintained, though not necessarily in its current form... Certainly
looking towards providing a nice and neat interface to the data submitted
is a good thing(tm)... But I don't think that reducing its functionality
is a particularly useful thing to do... At least not without considering
where said functionality can be placed so that people who do rely on it
can access it :)

Greg

Reply via email to