CGI::Lite, Titanium, Catalyst, Jifty, mojo ­— but mainly CGI-Lite...

LWP::useragent is also supposed to do cookies pretty well. I plan to tackle cookies myself and ssl in the next week.

Are you sure we need another module for this? Were you planning to release this or is it for internal use?

It will mainly be for internal use in my home made web portal. To release it I would have to write documentation and I'm not looking forward to doing that. I found out I'm not using a large part of CGI.pm and if i made the parts I do use and removed the need of CGI.pm the web portal will gain a lot of speed. I'm looking at CGI::Lite and it seems to have mostly everything I'm after the only think Im wondering about it is.

Does it work well with MOD_Perl?

Not mentioned yet: Mason and CGI::Minimal. The later page has some comparative performance benchmarks for the various CPAN CGI modules, you might want to check that out because the ticket here will be performance.

I haven't looked at the source for CGI.pm, but whatever it's state (nb, I am not sure how these techniques can be considered "outdated" since they involve exactly the same thing as they always have), it has one thing going for it: a long history with hundreds of thousands or millions of users. That is a pretty significant pedigree.

I only use a CGI process when there is no other choice anyway, and WRT the module, I don't use most of the methods, to be honest -- I could do without the HTML builders and such. But, considering a) it exports those methods selectively, and b) it is so well playtested, I would be very unlikely to bother using something new unless there is a good reason to do so, and I do not see any at all in your post.

The other thing I wanted to mention in defence of CGI.pm not being bloated is something that came up yesturday: mod_perl and APR::Table: why the madness?

Point being, I didn't realize CGI.pm was usable with mod_perl without Apache::Registry. And by using it, I was able to eliminate my use of three other modules (Apache2::RequestIO, URI::Escape, and APR::Table). If "residential memory usage" is any indication, this was a substantial reduction -- CGI.pm added less than 10% of what those other three did. So methinks it not so "bloated" (and again, it can export a select batch of methods; what is it specifically you mean by "bloat"?)*

So not to be discouraging, but you might want to consider that a lot of people like myself would consider the existing CGI.pm:

• Extremely reliable.
• Relatively streamlined.

If you have not already, you might also want to consider among your list of features that CGI.pm automatically uri decodes the input parameters.

Finally, if you think there are specific problems with CGI.pm, maybe it would be better to approach the current developers and offer to correct those, rather than write some new alternative by yourself.

* coding style is not an indication of bloat, eg, if you mean someone did something in five lines "that I could just as easily have done in one", you might want to think harder about what efficiency really means. It has very little to do with compressing the code base. Less code is not by definition "less bloated" than more code, and could easily be "more bloated" if by "bloat" you mean use of resources which longer, lower level code is more likely to reduce. Again, I have not looked at the source but, having read books by Lincoln Stein, the original author, I truly doubt he was a bad programmer...

I haven't looked at the source at CGI.pm

I can tell just by the way you talk about CGI.pm.

And by using it, I was able to eliminate my use of four other modules

Using CGI.pm and mod_perl version 1 module Apache is required in CGI.pm. Using CGI.pm and mod_perl version 2 modules Apache2::Response, Apache2::RequestRec, Apache2::RequestUtil, Apache2::RequestIO, APR::Pool are required in CGI.pm.

I would say CGI.pm is bloated because of the massive amount of redundant coding and the fact that the file size is about 262,144 bytes give or take a few bytes. Perl still has to open and read that file. Others will see the size of the module as a lack of optimization or re-factoring. In both of those cases it proves to me its a bloated code if your not going to use the hole module.

Using CGI.pm and mod_perl version 2 modules Apache2::Response, Apache2::RequestRec, Apache2::RequestUtil, Apache2::RequestIO, APR::Pool are required in CGI.pm.


In fact, it was APR::Table that was the fat cat in the bunch, but point taken.

I would say CGI.pm is bloated because of the massive amount of redundant coding and the fact that the file size is about 262,144 bytes give or take a few bytes. Perl still has to open and read that file.

Okay, well I have now glanced at it. Looks to me like most of that is actually comments. Too many comments can be as irritating as too few, but in any case, they are irrelevant to the compiler/interpreter. Further:

1. 260k is smaller than many or most image files, there is no significant overhead here.
2. CGI.pm only needs to be loaded once if configured into apache, so the size of the source file is generally irrelevant. Also I'd repeat that "more code done well will be more efficient than less code done poorly" (which may or may not be true here). Just judging a program on the total mass of the source is not very useful.

Again, I think you need to present some concrete examples of what you mean by "redundant" and "bloated". Simply saying "Well I can tell you haven't read the source" is akin to saying "I can't give you any reason, just take my word for it" -- if you cannot demonstrate something in real terms (not vaguaries), how do you expect potential users to take you seriously?

Thanks for raising the issue tho, in the future I may make use of CGI::Minimal instead ;P