At 5:00 PM -0700 9/14/06, Aankhen wrote:
There were a few discussions with Juerd and others in #perl6 about
CGI.pm in Perl 6... if anyone's interested, I'll look for the logs.
The major feeling was that there should be no CGI.pm (if someone was
hellbent on using it, they could use the Perl 5 module).  Rather,
there needs to be proper seperation of concerns.  Maybe instead of
just importing CGI, you'd now import HTTP::Request::CGI and
HTML::Generator (I'm throwing names out at random, although I did
write HTTP::Request::CGI as a subclass of HTTP::Request whose members
are populated in a manner similar to CGI.pm's parsing of %ENV).

While I wasn't involved in that discussion, I agree with the sentiment you have expressed here, wherein there should be no "CGI.pm" in Perl 6.

(Moreover, we should probably make an effort that no Perl 6 module will have just a top-level namespace as its name unless it is a core module or it is a framework.)

Having had some prior experience in tackling this problem (eg, CGI::Portable), I will endeavour to work on / help with the Perl 6 analogy to HTTP::Request/Response, so to replace the use of corresponding aspects of CGI.pm.

Note that the design strategy I had used in CGI::Portable was to have a pure container object representing a request and/or response, which was used sort of like this:

1. At start of handling an HTTP request, the main server runloop creates a new Request Container and has it populated by invoking a module function that knows about a particular environment, such as IO::Socket vs mod_perl vs CGI or whatever.

2. The main runloop calls the application's main per-request handling function; that function reads its HTTP input details from Request Container and writes its HTTP output details to Response Container.

3. At end of handling an HTTP request, the main server runloop invokes a module function that knows about a particular environment, and that function outputs whatever the Response Container represents.

Note that, in the general case, the Request/Response containers would not have any ties to outside environment, though in specific cases where input and output are too large to easily fit in RAM at once, there can be enhancements.

-- Darren Duncan

Reply via email to