Response to Ejecting CGI.pm From the Perl Core
In Ejecting
CGI.pm From the Perl Core chromatic discusses the pending deprication
of a storied module. I needed to address a perhaps overlooked aspect
of the argument.
Nearly all web ui are written to support small usergroups inside some
kind of organizational infrastructure.
Very few websites are moderate to large. Most are small. With maybe
a few dozen to a hundred or so users. Most are tools used to provide
some internal organizational function. Not to serve media websites to
thousands viewers or general public readers. On the complementary side
of this, most perl users have some other axe to grind. Web development
is at best a side interest. Or maybe a self defense skill they picked
up out of a need to automate away some function of their job.
Strangely, Apache and CGI fit well into this niche. the local
sysadmin/devops person probably already had apache running for some other
reason. Enabling cgi in some subdirectory was just a matter of editing
a config file and restarting the server. Now he could drop files into
the cgi-bin directory and off they went. Needs were met and the work of
automating away administrative jobs with simple perl scripts could begin.
Life was good.
When there was only one way to do a thing it was pretty obvious how to get
that thing done. Now things have changed. The web is not as simple as
it was. There are so many different approaches to delivering information
to the browser. Client side frameworks, server side frameworks, hybrid
solutions, SOAP, REST, java applets, javascript apps. The list seems
endless. Browsers are no longer "thin clients" Today they are full
function platforms. That's a good thing. But it does complicate things
for beginners and casual users.
For me perl is about two things. Its about making the easy stuff trivial
and making the complex stuff possible. How best should the casual perl
user deploy a web page? How best should he manage the organic growth of
his script base of small pages? Should he choose a big webserver such
as apache or ngenx and integrate through that? Or pick one of the stand
alone perl based solutions such as hypnotoad? starman, one of the others?
Or bail on the whole perl thing and pick a CMS and build from there?
Today the average sysadmin is going to have a suite of different UI
delivered via a web. Wiki, directory services, ticketing, revision
control, monitoring etc. Many depending perhaps on Apache. How best
to integrate custom local tools into that mix?
The perl community needs a new "best practice" approach for delivering
small dynamic web user interfaces. It also needs good documentation on
how to do it. Once upon a time that best practice was Apache and CGI.
Part of perl's popularity in the 90s and 00s was exactly because of
this combination. Also the availability of good documentation like
the CGI.pm perldoc, Ovid's CGI tutorial and the tutorials by Rob
McCool at NCSA. We've fallen off our game. We have no such de facto
boot strap best practice any more. The casual web script developer,
The one with some other axe to grind other than developing a website,
will probably fall over and just use Wordpress, Jango, Drupal, rails
rather than try to wade through the mess of different perl offerings.
None of which seem to have a solution that solves the casual users needs.
Plack, PSGI and technologies around it may be revolutionary. But it
is meaningless middle-ware that just does not seem to fill the niche
occupied by the average CGI.pm user today.
Chris has been building tomorrow's legacy systems for more than 2 decades. His favorite way of achieving this is through what he calls programming by research and find that perl and the CPAN provide a rich platform, ecosystem and community to succeed within.
Most sysadmin switched long time ago away from Apache, because nginx, lighttpd, thttpd and other webserver are just 10times easier to handle, manage and understand. Configuring Apache is a pain against those others. I am totally happy to lost all knowledge about it. Even tho I don't understand why this is at all related to CGI.pm.
And now about the real topic that is relevant in here.... I have no idea what you talk about, in all those text you totally ignore this: https://metacpan.org/module/Plack::Handler::CGI The only thing you can say is now "hey you have to install something todo a webapp", but I still think that people working ONLY with Perl core should REALLY recheck their environment.
So seriously, can you explain now what is forever and ever blocking those people that are REALLY installing the latest Perl and still have no clue how to handle it (which is like a strange setup, 5.18 will not go into distributions for a long long time, and at this point those distributions also will have included Plack, because this is much older)
Please stay on technical facts, instead of trying to generate a vague cloud of impressions you have for yourself. Plack is not "a huge monster" its as simple as it sounds, and it handles lots of more details then CGI.pm does, which are VERY important. Also its very activly maintained.
I am definitly one of those guys who want to have Perl as stable as possible, and I agree that removing such a module is a "bold move", but we have many bold moves in 5.18, and anyway some stuff (especially like "legacy code") will break if you just upgrade it to 5.18, so its not a big deal to let them also switch to Plack (as in: they dont even need to understand it, the example is there, copy&paste, and working like before). It is not breaking backward compatibility.
Oh just realizing it was not removed in 5.18 ;) but its planned to be removed in 5.22 (just to correct myself)
Oh and another small correction: The HTML generation of CGI.pm is of course missing, but if you need some replacement for this, I will personally make one for you :).
BTW: miyagawa reminded me that of course you can still install CGI.pm of course, I wanted to just clearly point out that Plack is not a big evil monster, its as simple as CGI.pm, and noone needs to be scared.
What do you get from CGI.pm that you don't get almost just as easy using the Plack toolbox?
use Plack::Request;
my $app = sub {
my $request = Plack::Request->new(shift);
# you code here
};
Personally I am not missing the HTML features from CGI.pm, but if so then add HTML::Tiny to the above. And presto, you have the same features as with CGI.pm.
Of course, just having the same feautes is not a reason to shift and certainly not if you have a large number of scripts using CGI.pm. But as already said, CGI.pm will be available at CPAN (and quite probably in most Linux-distributions) as long as anyone want to maintain it.
But the really fun part comes when your script starts to evolve. Porting the above snippet to something kept compiled persistently including some persistent data stored between requests is trivial. It is already done, just look for Plack::Handler::* and see what works for your webserver. (Yeah, this requires some configuration of the webserver, but probably less of what it would take to make a CGI.pm using CGI script persistent.)
If you just need a better CGI.pm than CGI.pm parts of the Plack ecosystem, then I don't think it is any harder to use Plack that it is to use CGI.pm. In addittion you get a maintained, leaner, and more flexible system.
Granted, the "just the better CGI.pm than CGI.pm" parts of Plack might be a bit under announced, but it is there without having to make lots of enterpricy decisions.
FYI only:
I use Perl v5.8.0 on windows (ActiveState).
When I go into ppm and type 'search plack' I get 'no matches for plack'. When I go into ppm and type 'search CGI' I get 410 different modules.
I know ActiveState is way behind the times, but I wanted to point that out.
Mike
Plack requires perl 5.8.1 which soon will be 10 years old. perl 5.8.0 is usually not recommended as it had some problems, which were fixed in 5.8.1 and 5.8.2. You should upgrade to at least perl 5.8.9, ActiveState improved ppm in that version. 5.16.3 would be better.
> I use Perl v5.8.0 on windows (ActiveState).
That is a 10+ years old release of perl. Are you really surprised its modules are way outdated?
Uhm, CGI and CGI.pm are not the same. Your whole argument is about CGI alone, and has nothing to do with whether you use CGI.pm for the job or not.
You can write CGI scripts with no modules at all. CGI.pm is just a better way to write CGI scripts than nothing-at-all is. And Plack is an even better way yet.
Both CGI.pm and Plack take care of things you’d have to do yourself if you used nothing-at-all, but Plack (with Plack::Request and some kind of templating or HTML generation module, if you don’t go for an actual web framework) is much better factored than CGI.pm and makes other (much better) deployment options easy to pursue.
“Meaningless middleware”? What does that even mean? (What do you think Apache is to your CGI script? Yup, middleware. What are all of its
mod_foomodules? Yup – middlewares!)Thanks so much to you and Leon. I didn't know plack would not work with my version. I tried to upgrade all the way to 5.16.1 about 6 months ago, but it didn't work. These are notes from last Dec:
I just tried to upgrade from 5.8.0 to 5.16.1 (64bit) on one of my machines. Ran this:
ActivePerl-5.16.1.1601-MSWin32-x64-296175.msi
and it installed fine, but I can't find it.
I normally keep Perl in C:/Perl, but when I
go there it's still 5.8.0. I did a search for 'active' and '16.1' and 'Perl' and 'bin', but can't find it anywhere.
The answer is that it tries to install to C:/Perl64, but for some odd reason never creates that directory, or at least I can't see it or get to it by trying the address into file explorer, even though it says it installs fine.
This version of ActiveState also won't install over the older version. You have to delete the older version to get this to install.
End of December notes
I'll try an upgrade to 5.8.2 in a month or so.
@raudss.us: Most sysadmins have switched away from Apache a long time ago? You mean not counting the 50%+ that are still using it?
Well, I'm pretty late to this party, but I completely agree with Chris that ejecting CGI.pm is a bad idea. Like a host of the other core modules, it could certainly use a thorough housecleaning. But simply saying that something like Plack or Plack::Handler::CGI is "better" doesn't cut it unless they really provide equivalent functionality, which they don't seem to, at least to me. I certainly don't think that code is better simply because it is old, but it also isn't superior just because someone labels it as "modern."
There are plenty of valid criticisms of of CGI.pm, but at least it tries to help you produce valid html. The front page of plackperl.org doesn't even include a Doctype! Try out the w3c validator on this page. This sort of attitude is fine if you are just selling soap or trying to get hits for your blog. But some of us might want the html our scripts produce to still be usable in 5 or maybe even 10 years.
For a specific example, what replicates CGI.pm's dead-simple form handling? Your script can produce a form, and if you call it with some of the paramater values specified, these get placed into the form elements automatically, with no additional work.