Re: (tye)Re: CPANPLUS

[sauoq]

Please, please, please, call it Net::CPAN. Then we can get CGI renamed Net::CGI.

Yuck. No. I wouldn't agree with either of those names. Both CGI's and CPAN's relationship to networking is peripheral.

CPAN uses various means to retrieve modules over the network but its real job is to determine dependencies, build, and install those modules. Certainly CPAN could have the functionality to access a local archive via the filesystem rather than the network. I don't use CPAN or CPANPLUS (I answered "make" on the poll) so for all I know one or both already have that functionality. It might be especially useful where institutions keep a local CPAN mirror and make it available to their user base via NFS.

CGI is simply a platform independent interface by which information servers may run external programs. In reality, this is only true for some definitions of "platform independence" and "information servers" but that's its stated goal.¹ It currently requires that the external program knows some things about the protocol that the information server is using but the actual network communication takes place through the server itself.

So, I think putting either CPAN or CGI in Net::* would be a mistake.

I wouldn't mind seeing name changes for B and O though.

¹That is, its the stated goal of the draft CGI specification not of the CGI module.

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

[tye]

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

As for CPANPLUS, if they want to keep "CPAN" in the name, then the primary way they are going to attach to CPAN is via a network. I don't mind in the least if they decide that this is not really the central purpose of the module and call it something having to do with "module management" or whatever.

But the point is that the only modules that don't have "::" in their names should be all-lowercase, that is, pragmas. See Filehandles vs. Packages: And the winner is... for one good reason why.

Other reasons include the "I used CGI" problem. Having a "::" in a module name can avoid a lot of confusion.

        - tye (but I plan to switch to "Person::Tye")

[sauoq]

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.";