Let's start with the name. I see no point in renaming it unnecessarily. I see no point in lengthening the name, either. Then again, I've seen a lot of people abbreviate the oh-so-difficult to type 'you' to 'u', saving a whopping TWO characters per time! (Moral of the story, keep frequently used names short.)

I'm not sure what LWP has to do with *server-side* CGI programming, so I'll leave that alone. You lost me.

Now for the bloat. Let's have some figures. How much space are the unused functions taking up? Do you realize that they're autoloaded when necessary, by default? How about the savings the OO interface provides by not importing symbols?

There are legitimate gripes -- Lincoln does say it does too much in the documentation. He wrote his own autoload scheme. The HTML functions should be split into another module, loaded only when necessary. The dual OO-procedural interface sucks. From personal experience, though, he accepts patches. Start with perldoc -m CGI.

It's not like you don't have other good choices, too. There's CGI3 (yes, the successor to CGI.pm, though not quite ready yet.) There's CGI::Lite. You're even welcome to write your own.

To answer your last question, though, it'll be time to stop using CGI.pm when there's a good, well-tested, and robust alternative. Maybe you're the one to write it.

Update: "Bloat" is such an ugly word. I'd like to see someone actually measure it sometime. There are good reasons to be concerned about CGI.pm, and, in my opinion, you haven't hit many specifics. "I think it's bloated, and it's possible to have namespace collisions with the procedural interface."

You're welcome to think that way (and the collision part is right, but it's possible with lots of modules, if you're not careful), but I'd like some facts. If its perceived bloat is such a problem, surely that would be worth measuring. Otherwise, how can anyone write a replacement and prove it's any better?

It seems I wasn't being quite so lucid with my original thought, so I'll post once more to say that it is not that I think LWP should replace CGI. I take full blame for making my post a little unclear on that point...

My point, in fact, is that most people will strive to make their code as compact and efficient as possible, so why is it such a crime to abhor bloating in modules? If I haven't made my arguments agains the bloat clear, I also haven't heard any decent reasons why it remains. So far the responses have gone along the lines of "it's not killing me, so who cares?" And there's nothing I revile more than apathy. I hope it's not the sound of M$ worshippers I'm hearing (who cares about the excesses, it's easy to use!). Now to see how many feathers that remark ruffles... ; )

Back to the topic at hand, however, I'll throw out this quote from a message brian d. foy posted on alt.perl about the "dangers" of CGI's namespace hogging:

(the function names) conflict with similar function names in other modules one is likely to use with CGI.pm, such as URI.

I won't pretend to be a perl guru, so my writing a new CGI module will have to wait a while. To show my ignorance, until I read that post I had been happily using CGI without a care in the world. I now find myself a little more wary about where and how I use the CGI module, and that's what prompted me to start this thread.

matt

Adding to what others have already said:

CGI.pm implements its own autoloading scheme, which means that no function is loaded until you need it. This means that in normal use the module is actually a lot slimmer than it might look.

As for the namespace issues. I always use the procedural interface which gives me complete control over the functions imported into my namespace. Given that most of my HTML is going to be stored in some kind of template, many of my CGI scripts start like this:

use CGI qw(param header);
[download]

as those are the CGI.pm functions that I'm going to use.

Having said that, I do think that if the HTML functions were pulled out into another module so that CGI.pm just dealt with the CGI protocol, then that would be a good thing.

"The first rule of Perl club is you don't talk about Perl club."

Regarding namespace issues, use the object syntax instead of the procedural syntax. And I guess the HTML element creation aspects can be seen by some to be overkill, but memory is cheap. So I don't see that as a big problem either.

And what does libwww-perl have to do with this discussion? The modules serve entirely different purposes. And regarding referring to CGI.pm as "old", well, you can also consider that to mean well-debugged, mature and time-tested. Furthermore, your quote states unequivocally that he is still working on the module on a regular basis, so it is far from being out of date.

Did you have some valid gripe with CGI? If so, do state it. And check out Apache::Emulator which just came out which has a neat way of making it so that CGI programs can move to mod_perl with no porting... Apache::Registry inverted.

I think he was pretty clear on his gripes with CGI.

CGI.pm does more than it should, it's not neat and the "mainstream perl culture" pushes it mainly due to its status. Nothing serious, just his view and shared by some others including the CGI.pm author himself.

I think CGI.pm could be renamed... possibly to a name that reflects all that it does and its size. Who likes CGI-HTML-HTTP-BundleByStatus.pm ?

Even as I say this, I recommend it to everyone learning perl, just don't get to attached to it :)

Tiago

I'm really not looking for a fight over CGI.pm, I just wanted to hear what other people had to say about it. I also use the module quite extensively when I have to write any scripts for the web, but my point is that I hardly use it for anything but obtaining parameters from html forms.

As well, I was not making the claim that the LWP modules should be used instead of CGI.pm, but the name just sprung to mind when I was thinking of another web-related module to chant rhythmically to myself.

My gripe, then, if I have to have one, is whether there is a need for so much baggage and repetition among modules? It seems that a lot of CGI.pm has fallen by the wayside as newer and more task-specific modules have been developed, so why hold on to all the bloat?

matt

If you are writing web client software, not using LWP would be a major oversight. So yes. Add that to the chanting litany. :)

I've used CGI for fun and have just started using it for profit just last week. I agree that it would be nice to have a module that was more easily broken down into its functional elements, but given that what we have works I don't see compelling reasons to change it-- at least not quickly.

On the server, my first guess is that speed is related more to your processor, your RAM, and whether or not you are maintaining your perl script in memory using something like mod_perl, than it is going to be related to whether or not the CGI module itself is "bloated".

As to whether we are "over loading" by bringing in functionality that we aren't going to use when we "use CGI;", so what? Every time I load perl I load lots of stuff I don't need-- it's an inherent danger in an interpreted language. The resulting executable is a hybrid of the interpreter and my code. And with a language that allows fancy stuff like eval() it gets even worse. Imagine a native C program that compiled and ran variable C code on the fly. (There's your spooky thought for Halloween. *grin* )

From the CGI manpage:

BUGS
       This module has grown large and monolithic.  Furthermore it's d
+oing many things, such as handling URLs, parsing CGI input, writing H
+TML, etc., that are also done in the LWP modules. It should be discar
+ded in favor of the CGI::* mod­ules, but somehow I continue to work o
+n it.
[download]

I suppose the next question is: what's being done about it? Are the CGI::* modules a straightforward attempt to replace CGI.pm?

conv

I'll bite. I think CGI takes on a bit too much as well. I love it's form handling, but it continues on way beyond the CGI. I'll keep using it for a couple of reasons though, the primary?

I don't know enough to confidently evaluate the alternatives:

• CGI::Minimal
• CGI::Base
• CGI::BasePlus
• CGI::Lite

This is just a partial list of the CGI namespace that deals with it. Some of them don't seem to be actively maintained (rather important). Is one of them a stripped down/refactored CGI.pm? How much testing have they gone through? CGI.pm is part of the standard distribution, should another become the de facto standard?

If Mr. Stein were willing maybe a group could help him factor the code out into some subclasses and have CGI.pm inherrit from them (for backwards compatibilty). This (to my rather unknowledgable view) would seem the best of both worlds. It would stay a standard while those wanting a lighter weight solution could use a base class. From what I understand thousands of development hours in writing and lots of testing went into CGI.pm. Even thinking of throwing that away seems criminal.

Update: Perhaps that "Even thinking of..." was a bit too much hyperbole. What I really meant was just abandonning the code base instead of exploring the possibility of refactoring is criminal. I agree completely that it is way too much bloat especially in a "typical" CGI environment (w/o mod_perl or the like).

Cobol has had many more hours and testing thrown at it, is it criminal to program in Perl?

Personally, I cut and paste 20 to 50 lines out of CGI.pm that I actually use into my CGIs, and leave the rest where it belongs... in a library on the disk, rather than parsed and compiled into my RAM. (even parts that aren't compiled take up cache space, to get started, so there is no way around extra resources being gobbled)

But then, I'm not using it for HTML generation. I use HTML for that... along with HTML::Template of course. For people writing a CGI, most of CGI.pm is bloat, unless we've forgotten what "CGI" means. I think 90% of it should be split off into something like HTML.pm. Of course, momentum is going to prevent that, which is why I cut and paste a few functions... muchly that means the encoding and decoding functions...

The good news is, since we should usually be using mod_perl anyways, Apache.pm doesn't suffer bloat in the same way.
--
Snazzy tagline here

CGI::Lite can be used in place of CGI if you're only using it to get at form options (and just printing out hand-carved HTML). I've used it myself and it's a fairly good, stable module to use w/o CGI's bloat.

--
$Stalag99{"URL"}="http://stalag99.keenspace.com";

For getting params, it's identical to use Apache::Request as to use CGI.pm. The advantage of CGI.pm is its generation of HTML elements, everyone realizes, but that itself is a no-no if you're working with HTML designers, where you want to separate the HTML from the Perl as much as possible.

About the LWP part, I'm kind of confused, but I guess I never happened to use the LWP-ish parts of CGI.pm. I think, if you only need to use the LWP-ish parts, then definitely use LWP. Sometimes I just 'use CGI::Util' say, if I want to URL-encode something, or CGI::Cookie.pm for cookies (actually I would use Apache::Cookie, but anyway... :)