Beefy Boxes and Bandwidth Generously Provided by pair Networks
good chemistry is complicated,
and a little bit messy -LW
 
PerlMonks  

Remove CGI.pm from Perl Core?

by rpnoble419 (Pilgrim)
on May 27, 2013 at 16:52 UTC ( #1035434=perlmeditation: print w/ replies, xml ) Need Help??

I'm posting this for all monks to follow up on. I think our community input should be added to the overall chorus. The entire posting can be found on the Perl Weekly by Gabor Szabo at http://perlweekly.com/archive/96.html

To save some time the basic issue is should CGI be removed from the CORE set of Perl modules http://www.modernperlbooks.com/mt/2013/05/ejecting-cgipm-from-the-perl-core.html

The argument against CGI is that is no longer best practice. In my option that may be very true as the code is old. I my self do not use half of the functions in it (I use the just the $q->param() mostly) and I never use it to generate my HTML (I use Templet::Toolkit). I agree with the post by chromatic (see above link) that CGI should be re-written to conform with the new Perl Best Practices.

What do you think?

Comment on Remove CGI.pm from Perl Core?
Re: Remove CGI.pm from Perl Core?
by chromatic (Archbishop) on May 27, 2013 at 17:11 UTC
    I agree with the post by chromatic (see above link) that CGI should be re-written to conform with the new Perl Best Practices.

    I hope I didn't give the impression that I believe that! Any code that's currently using CGI.pm can safely continue to do so. That's fine—that backwards compatibility is important.

    Personally I wouldn't recommend any new code use CGI.pm. Keeping CGI.pm in the core elevates it artificially to a recommendation in many minds, and that's not great. You're far better off using something compatible with PSGI (even Plack::Request directly, or at least Web::Simple) than CGI.pm.

      I'm sorry if I misinterpreted you. Though having a modern way of using CGI is still a good idea. Sometimes we don't need the overhead of a "Framework" to get a task done. That is where I think the future of CGI may be...

Re: Remove CGI.pm from Perl Core?
by vsespb (Hermit) on May 27, 2013 at 17:27 UTC

    I think CGI is perfectly valid protocol (even if we compare with fastcgi, psgi, mod_perl). For big, real websites, if's, ofcourse, not an option.

    But for testing, small sysadmin scripts/gui it's just ok.

    Also I think deploy of CGI script often easier.

    I have a CGI scipt, I installed 5 years ago. And I use it once a two years. Between runs and reboots it does not use cpu, memory and disk IO. What else can compete with that?

    However, I think CGI.pm should be removed from core, because

    1. Bad implementation

    2. Perl maintainers can spend time for something more usefull

    3. Indeed, it's easier to update CPAN module with security fixes, than whole perl

    4. It still can be on CPAN

    5. Someone can write a better replacement

    6. Someone can put this replacement into core

    7. Unix Distribution maintainers can release package with CGI.pm and make Perl depend on it, if they want to

Re: Remove CGI.pm from Perl Core?
by ww (Bishop) on May 27, 2013 at 18:17 UTC
    paraphrase from another context:
    You'll have to pry it out of my cold, dead fingers!

    One example why: I have a client whose on-line ordering system is pure CGI (well, there's a little js, purely for rendering on the "order" page itself. The system -- login, verification, presentation of available stock in an order-sheet format; calculations including volume discounts; billing; and order confirmation to client & customer -- is probably hit about 10 - 35 times per business day. At an average thousand dollars a pop, my client is quite happy (particularly since a significant part of his customer base is computer-phobic)... and -- as we all know, a happy client makes for a happy dev.

    It eats almost no cycles, costs the client no significant o/head and "just works," as it has since being debugged nearly a decade ago.

    Granted, that's not a major argument for retaining CGI.pm in core... and, granted (again), were I just starting today to scope out a system for this particular case, I might go another route. Hypothetical "best practice" (because best practice in Case A may not be so in Case B) considerations don's cut it with me; even less so does any sort of "code purity" (or is it philosophic correctness).

    P.S. It would be a major misunderstanding to read this as a slap of any sort of chromatic or any other advocate for improving Perl. It's not and I do admire such well-considered advocacy.


    If you didn't program your executable by toggling in binary, it wasn't really programming!

      Granted, that's not a major argument for retaining CGI.pm in core...

      That's right. It's not going away from the CPAN. All ejecting it from the core means is that, when you're installing custom code you wrote on the server, you may have to install CGI.pm as you should be doing for bug fixes and security improvements anyway.

        Oops!

        Very well taken. Think I hv not updated the server copy in > 18, 24? months. Shame on me and thank you for an important point + +.

        ... But I still don't want it taken out of core.


        If you didn't program your executable by toggling in binary, it wasn't really programming!

Re: Remove CGI.pm from Perl Core (why wait)?
by Anonymous Monk on May 28, 2013 at 03:28 UTC
Re: Remove CGI.pm from Perl Core?
by sundialsvc4 (Abbot) on May 28, 2013 at 03:33 UTC

    Isn’t there an awful lot of other, i.e. “sexier,” CPAN code that nonetheless has CGI as one of its prerequisites?

      sn’t there an awful lot of other, i.e. “sexier,” CPAN code that nonetheless has CGI as one of its prerequisites?

      What does that have to do with anything "sundialsvc4" ?

        Forgot to sign in?   (Will every Monk please keep things &rsquou;round here “strictly business” and just skip the jabs and downvotes?   They get wearisome.)   Anyway ... it was a serious question/comment.

        Take CGI::Application as just one example:   it’s slightly hidden, but there it is ...

        # Include CGI.pm and related modules require CGI;

        ... and the list of dependents is really quite large.   While CGI might not be the best way to run a big, fast web-site, the original way of automating a web-site is still in very common use.   I sensed in the original post (my view only ...) the notion that CGI should be dropped because it is unfashionable.   It is stable, and anything but large, and I suspect that it is much more widespread than one might prefer ... and still doing its job.

      Unless I'm missing something, "dependency" doesn't mean "must be in core". Just install it if you still need it.

      -- FloydATC

      Time flies when you don't know what you're doing

Re: Remove CGI.pm from Perl Core?
by ruzam (Curate) on May 28, 2013 at 04:36 UTC

    Well, this is just my opinion, but I feel if you remove CGI from core you might as well declare Perl dead (for the web at least). The entry bar to Perl beginners needs to be lower not higher.

    As long as CGI is in core, it's a simple step to use it and get on with the business of showing future developers how to do cool stuff on the web. Those helpful tutorials on the web make it easy to 'get Perl' followed by 'use CGI' and end in 'hello world' before anyone loses interest. Without CGI in core, it's 'get Perl' followed by discussion about which CGI modules to use, followed by more discussion about how to get modules from CPAN, ending with the beginner googling the next web tutorial looking for one that 'just works' without all the fuss (and another PHP coder is born). CGI in core is a carrot to get past the Perl learning curve after which, better CGI replacements can be evaluated with more experience.

    But it shouldn't be left to rot in core either. Nothing in core should ever be allowed to become stale and outdated. Better that it be updated in CPAN than neglected in core.

      .... and another PHP coder is born...

      If ease of deployment is the primary concern, nothing beats PHP anyway, so either someone comes up with something even easier to deploy (and maintain) than mod_php or we've already ceded that cohort.

      If the alternative is people switch to (say) Ruby or Python, then they're going to have a dilly of a time realizing that none of Django, Rails, Flask, Sinatra, et al are core libraries in their respective languages either.

      Nothing in core should ever be allowed to become stale and outdated.

      Without a small army of volunteers, how do you turn should not into does not?

        If one is actually talking about getting web work done, vs. religion, then PHP does deserve some praise ... before being taken out in front of the wall at dawn, and shot.   ;-)   Most of us have to admit that we have some responsibility somewhere for some big PHP monstrosity, probably written in some (equally monstrous ...) PHP version that is no longer being maintained anymore, but which remains in service (and locked in limbo) because someone on the PHP team decided to make some feature of the language “–er” in some incompatible way.

        Nevertheless, what they do with their tool is their concern, not Perl’s.   At the end of the day, they’re all just ... tools ... and we probably use many of them, before returning, with a gentle sigh of relief (and perhaps a nip of fine cognac), to ... Perl.   :-D

      But it shouldn't be left to rot in core either. Nothing in core should ever be allowed to become stale and outdated. Better that it be updated in CPAN than neglected in core.

      I must have missed something. Will moving it from core to CPAN result in its being updated more and neglected less?

Re: Remove CGI.pm from Perl Core?
by LanX (Canon) on May 28, 2013 at 09:06 UTC
    I think core distribution should always be bundled with a web module, which allows to immediately start a web-app from scratch off the cuff.¹

    I.a.W before excluding CGI from core a better alternative should be included in parallel for a considerable transition time.

    Maybe something like Mojolicious?

    Cheers Rolf

    ( addicted to the Perl Programming Language)

    ¹) hopefully clearer now! =)

      I think core distribution should always be bundled with a web module, which allows to immediately start a web-app from scratch.

      from scratch is very low-level, why bother anymore with so low-level?

      Sure File::Spec does job, but I'd rather Path::Class anyday

        Sorry, wrong wording!

        I meant instantly from a "virgin" installation.

        And Mojolicious is pretty high level compared to CGI and has no dependencies.

        Cheers Rolf

        ( addicted to the Perl Programming Language)

      ... whereas I disagree with that notion quite strongly.   Although many of us may be accustomed to spending most of our daily grind, grinding out web applications, the Perl language is used for anything and everything, every day.   The Core ought to be a collection of both mandatory-things and often-useful things ... but, in the latter case especially, always rather small things.   No kitchen-sinks allowed here.

      This is one of the most significant impacts of PHP’s very un-modular architecture, and one that we want to avoid in this tool:

      -rwxr-xr-x 1 root wheel 32222704 Jul 31 2012 /usr/bin/php
      -rwxr-xr-x 1 root wheel 86000 Jun 24 2009 /usr/bin/perl

      “Admittedly by-design,” PHP is a great big phat language that is targeted for writing web-sites and therefore good for not much else ... although I certainly have seen it being used for scripting.   Perl’s “Core” should be lean, mean, and useful ... and emphatically not a substitute for having to separately install modules from CPAN (or elsewhere) as an additional step.   (We already have several “bundled packages”available to simplify common installs.)   PHP’s designers intentionally did what they did for the PHP tool, and I am here neither to praise nor to bury that engineering choice.   But to do the same, IMHO, would not be the right thing to do engineering choice for the Perl tool.

      IMHO, the true strength of Perl is:   91007 Uploads, 27617 Distributions, 121586 Modules, 10676 Uploaders ... good for what ails you, no matter what it may be, and all in (to quote Disney’s Aladdin), “itty-bitty living space.”

        Your perl binary is little more than an empty shell -- all the fat (1,5 MB or thereabouts) comes dynamically linked from libperl. See ldd /usr/bin/perl

      So, if Mojolicious, say, were to find its way into core, would it make sense to replace the "more essential" parts of CGI.pm with wrappers for equivalent Mojolicious functions? I realize that this question is or at least borders on being irrelevant to the question of whether either belongs in the core, but maybe it could be a step in cleaning up CGI,pm...

        would it make sense to replace the "more essential" parts of CGI.pm with wrappers for equivalent Mojolicious functions?

        No, you can't change the guts of CGI.pm without breaking everything that makes CGI.pm what it is (CGI.pm), that's how old and quirky feature-full it is -- one of its design features is that you can edit CGI.pm to configure it how you prefer

        but maybe it could be a step in cleaning up CGI,pm...

        Not really, you're not the first to express similar thoughts in this discussion, but have you ever looked inside CGI.pm or edited it or submitted a patch? Heard of CGI::Simple?

        Nicholas Clark recently said This is always the case. Talk is cheap, and there is a lot of it.

        All the folks who are really interested have started forking already :)

Re: Remove CGI.pm from Perl Core?
by james2vegas (Chaplain) on May 28, 2013 at 09:26 UTC
    Yay, let's remove CGI.pm so we can see more code splitting query strings manually, %ENV checking and writing out HTTP headers with print <<HEREDOCs. Also, no thought is given to providing a replacement, apparently including Plack instead is laughable, though including a subset of Pack, something like Plack::{Request,Response,Runner,Handler::CGI} would not be horrible.
      I wholly concur with your point. CGI.pm has useful functions, but it is still 90% crud that probably should not be used (namely, the parts that output HTML. And the double procedural/OO interface).

      Core needs a module that speaks CGI but only does the bare necessities: Query strings, cookies, HTTP headers, HTML/URI escaping... and that's about it? CGI::Lite?

        Core needs a module that speaks CGI

        Sure it doesn't ;)

        CGI::Lite?

        Nope, a module that hasn't seen an update since 2003

      I feel like we really need to push Plack.

      It has plenty of CGI compatibility built in while promoting way better practices for free. People new to perl could easily learn on Plack and then scale up as needed without having to migrate to anything different, while allowing a broad spectrum of deployment options (FastCGI, mod_perl, Starman, etc.) CGI is heavy, old, bloated and really easily replaced by Plack in every sense in my opinion.

      Three thousand years of beautiful tradition, from Moses to Sandy Koufax, you're god damn right I'm living in the fucking past

Re: Remove CGI.pm from Perl Core? (Plack / PSGI Stand-Alone)
by Corion (Pope) on May 28, 2013 at 13:57 UTC

    Tatsuhiko Miyagawa and Johan Vromans point out a very nice approach to creating a Plack stand-alone executable on p5p:

    % cat > app.cgi package main; my $app = sub { return [ 200, [ "Content-Type", "text/html" ], [ "Hello" ] ]; }; Plack::Handler::CGI->new->run($app); % cat `perldoc -l Plack::Handler::CGI` app.cgi > app_bundled.cgi

    ... or, creating a Mojolicious::Lite app:

    $ cat > myapp.pl use Mojolicious::Lite; get '/' => sub { my $self = shift; $self->render(text => "Hi"); }; app->start;
    The myapp.pl can work as a CGI, but also as a PSGI handler if you deploy to platforms that only supports PSGI apps and *not* CGI, such as Heroku, DotCloud and Stackato.

      % cat `perldoc -l Plack::Handler::CGI` app.cgi > app_bundled.cgi

      Why not use fatpacker if you've got linux where fatpacker works ?

      OTOH that won't work as Plack::Handler::CGI has pod in __END__ section, so app.cgi is in __END__ section, so there is no app

Re: Remove CGI.pm from Perl Core?
by FloydATC (Chaplain) on May 28, 2013 at 17:53 UTC
    I see many people point out that they only use a tiny subset of CGI.pm these days, params() being the most common. I couldn't agree more. I never understood why in the world anyone bothered to implement a h1 method -- who in their right mind would use something like that? :-)

    print h1({-align=>left}, 'What be this see-ess-ess thing?');
    Would it be possible to chop CGI.pm into pieces, rewrite the stuff that's still in use, call it CGI.pm and keep it in core, and then eject the more exotic/old-fashioned stuff so that if you still want to use it you would install something like "CGI::Compat", "CGI::Legacy" or similar from CPAN?

    Either way you choose to eject it from core (as I'm sure will happen sooner or later), it's not like this change would all of a sudden make all existing installations burn down, fall over and then sink into the swamp.

    -- FloydATC

    Time flies when you don't know what you're doing

      Would it be possible to chop CGI.pm into pieces, ...

      :) Another one, of course it possible, its already done, its called CGI::Simple -- this doesn't change anything about CGI.pm

Re: Remove CGI.pm from Perl Core?
by Anonymous Monk on May 28, 2013 at 19:09 UTC

    I agree with the post by chromatic (see above link) that CGI should be re-written to conform with the new Perl Best Practices.

    I'm pretty sure chromatic didn't suggest that at all

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://1035434]
Approved by davies
Front-paged by Arunbear
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others taking refuge in the Monastery: (6)
As of 2014-12-29 00:21 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (183 votes), past polls