Sorry, your claim that CGI.pm isn't for networking is, well, silly.

Saying so doesn't make it true.

CGI.pm isn't for networking. It doesn't contain any networking code. It doesn't read from or write to sockets. It reads from stdin and its environment and writes to stdout. (Under certain circumstances, it will also read or write files.)

CGI is an interface between server software (specifically an information server) and external programs. The interface defines what information the server makes available to those programs as well as how that information is made available. It also imposes some requirements on the response.

As it stands now, external programs implementing CGI are required to "understand" some of the underlying protocol. Although this isn't desirable, in practice it is a minimal requirement: a script must output a content header. In some cases, NPH scripts for example, programs are allowed to handle more of the application-level protocol communication rather than just the content.

CGI is really its own thing. Ironically, the only CGI RFC is for SIP CGI. There has been quite a bit of work done on specifying CGI in general and "WWW CGI" in particular. Unfortunately, the effort has dwindled. I encourage you and anyone that reads this to visit http://cgi-spec.golux.com, join the mailing lists, and offer your support. The problem seems to be that people already think CGI is a standard simply because it is ubiquitous. If enough people show their interest, the author, Ken Coar, will almost certainly pick up the torch again.

Failing that, please don't suggest that we rename the CGI module Net::CGI. That would be reinforcing the misconception that CGI deals directly with networking, which it does not. Leaving it as a top level module makes the most sense.

-sauoq
"My two cents aren't worth a dime.";