Given the recent meditations and discussions regarding the utility of CGI.pm and why you should use it, I decided to see if there was an update.

While searching cpan.org, I noticed that there's a CGI3.pm, which appears to be an optimized version of CGI.pm.

I didn't see any related nodes on PM, so I thought I'd ask if anyone has any information, knowledge, or observations to share. Should we be using CGI3.pm instead of CGI.pm?

The docs for the module do appear to be very similar to those in CGI v2.60; I'm still working my way through the source of the two files.

--f

Replies are listed 'Best First'.
Re: CGI3.pm
by dkubb (Deacon) on Jan 22, 2001 at 16:19 UTC
    Ive used this module a few times, just to see how it worked. When you install it, it does a benchmark between it and CGI.pm, and the results are very much in it's favor.

    Anyone who's looked at the internals of CGI will agree that it's not the most efficient perl module. It's pretty big, and wears alot of hats. But it works, and works well. CGI3 has alot to live up to if it's looking at replacing CGI.pm as the de facto CGI module on CPAN - something I am not sure it's trying to do. In fact I'm not sure what it's intended purpose is.

    It's interface is similar to CGI.pm, almost identical AFAIK. I've noticed a few bugs/missing methods here and there, and emailed the Author, who is NOT Lincoln Stein, but rather a fellow named David James (see CGI3's README). He is rather proud of his module, which he should be, but bug fixes are slow to appear, it hasn't been updated on CPAN since August 24th 1999. BTW, he told me that Lincoln does the uploads in his CPAN directory, but does not develop the module.

    My experience testing it has been fairly positive. Most missing methods are non-critical. Alot of the :cgi-lib stuff is gone or missing, which may be a good or bad thing depending on how much legacy code you need to maintain.

    Just a few problems I have with it:

    • Lincoln didn't write it. Granted others could, but I trust his work, and think he has the knowledge to ensure that the quality/security is maintained.
    • Updates are rather slow. Something like CGI needs to be updated somewhat often, not once every 6 months.
    • It means a new round of security fixes and updates while reviews happen on the all-new revised code.
    • It was based on CGI.pm 2.60. CGI.pm is now at 2.74. Unless it's kept up to date, it won't become the successor.
    • Forking CGI.pm would generally be a bad idea. CGI.pm must maintain a constant movement forward, with unified code based. If a switch is going to happen, it has to be done fully, and in one direction, forward.
    • No apparent plans to move to CGI3, it "feels" like it was an experiment.

    All in all, it's neat to play with, but I would not recommend using it in production code:

    #Always use CGI;
Re: CGI3.pm
by extremely (Priest) on Jan 13, 2001 at 07:41 UTC
    Hey! You just gave me an IDEA. I am stuck in Jury duty next week. I'm going to dump a crud load of modules into my PDA and scan their source during the downtime...

    Yay!

    --
    $you = new YOU;
    honk() if $you->love(perl)

      I just hope the guys guilt/innocence doesn't lie in your hand..

      extremely: What, they used an array where they should've used a hash?! Argh, guilty I say, guilty!

      :-)

      -marius