The Perl 5 Porters list is discussing a proposal to remove CGI.pm from the core distribution. Per the discussion, this proposal is likely to succeed, and Perl 5.20 (released around May 2014) will no longer include CGI.pm as a core library.
The arguments in favor of this are:
- It's not great code: it does far too much (conflating HTML generation with parameter processing and cookie handling), its interface is confusing (the kind of halfhearted pseudo-OO that Perl 5 circa 1994 encouraged), and its implementation is weird beyond that (the last time I looked, it had a strange load-on-demand system to avoid the performance penalty of compiling a couple of thousand lines of Perl 5 code).
- It operates at too low a level: you need to understand far too much about how the CGI protocol works to use it effectively.
- Its execution model represents the lowest common denominator of web deployment; it hasn't moved much on beyond 1998 (with some code to support FastCGI and mod_perl, but not much else).
- It's harder to deploy that it seems, if you count the system administration work it takes to configure a web server for the CGI protocol.
- In almost every case, at least one of several plausible Perl web frameworks is a better choice.
The biggest criticism is actually a Perl success story. PSGI and Plack make developing and deploying Perl web programs so much easier that there's no credible reason to use raw CGI anymore, at least if you can install Plack or use a PSGI-compatible library. If you're tied to the CGI approach, Plack::Handler::CGI is a better alternative in every way, even for local development and testing.
The cons of ejecting CGI are:
- It's been in the core approximately forever.
- Sometimes it's the only thing available, if you're using a shared hosting account where you can't install CPAN modules and a bearded sysadmin somewhere refuses to install them for you.
In other words, the discussion on p5p seems to be that the burden of maintaining code that no one uses, no one likes, and no one really wants to maintain in the core is greater than the benefit of providing a mediocre out of the box CPAN-free experience to people who don't maintain their own Perl installations.
In other words, the dominant philosophy seems to be "CPAN is integral to the desired experience of Perl 5".
(I suspect that the CPAN-hostile environment which still promotes CGI.pm as the state of the art in Perl overlaps strongly with the older-is-better-stability-over-all enterprise Linux distribution group, of which Red Hat for example won't provide Perl 5.20 for several years, so the dominant web programming model of 1997 has yet another stay of execution. Hooray. Please feel free to join us in the 21st century sometime.)
Well, it won't affect a financial house I worked at, then. Until far more recently than you could imagine, CGI.pm wasn't allowed because “it was too big not to have bugs in it”. Yes, we were parsing $ENV{'QUERY_STRING'} well into this century …
I'm curious—how did they manage not to write bugs themselves? If you're rewriting libraries....
If we remove CGI, then we should replace it with something better.
I agree that CGI has not been best practice for a long time, but it was best practice for a while because the alternative was to parse and http queries and generate html entirely by hand.
Most of have worked in environments where external modules are forbidden, either because management is excessively risk adverse, or because the hosting company charges extra for installing non core modules.
Much as we in the perl community hate these backward working practices that don't embrace CPAN, they continue to exist and won't go away. We need to support those unfortunate users who have to work within such constraints.
For this reason, I think that if CGI.pm is removed, we ought to replace it with something else that is lightweight and represents best practice. My vote would be for Plack as it is small, has few dependencies, and is easy to enable in Apache (via Plack::Handler::Apache2::Registry). Idealy we should also add a templating module as well so that Plack users don't have to fill their pgsi with big blocks of sprintf to generate their html.
If you really think that "nobody uses CGI.pm" then you need to get out more often. It's used everywhere as far as I can see. Removing this will cause many problems.
It's wrong to say that no one uses CGI.pm. Bugzilla still uses it.
How will it cause problems? Who's upgrading to Perl 5.20 and refusing to install CGI.pm?
I meant among the participants in the p5p discussion.
Without a small army of new volunteers appearing to do the hard work of maintaining Perl 5, I suspect we get to choose between two alternatives:
In other words, the decision is very likely between yearly releases with bugfixes and optimizations and improvements or keeping things like CGI.pm as a core library. Even "core library" is a misnomer, as it's been a dual-lived module for a long time. At least with the yearly releases, people who don't use the CPAN will eventually get bug fixes and improvements to CGI.pm every five years or so, when their administrators get around to upgrading, but is that really the dominant use of Perl that the p5p development process should optimize itself for?
Who will upgrade to perl 5.20 without installing CGI from CPAN or the like?
Perhaps in about 2 years time when Debian Jessie becomes stable, with perl 5.20 as the system perl, but working under a grumpy sysadmin who refuses to install any Debian or CPAN package without a request in triplicate and a 6 month evaluation period.
Don't laugh, admins like that exist, and it is no fun trying to get any work done on a system they control.
I agree that that's no fun, but p5p's not willing to pay the price for that organization's problems. It's difficult enough to maintain the existing core. The maintenance burden of code that p5p can't even see is too high.