libwww-perl is one of those venerable CPAN distributions that has been around for years and for which there is simply no alternative. It makes writing www-clients very easy and offers a decent interface. Furthermore, switching to SSL-encrypted HTTPS will require very little or not changes at all to your code-base.
It has however quite a few flaws and makes in parts arbitrary assumptions that are difficult to get by.
We use it extensively at work where we are using HTTP as a sort-of RPC. We do stretch things a little but we are certainly still within the specifications of HTTP. We were therefore surprised and rather disappointed to see how many bugs this (supposedly) mature module has: It limits the amount of header-fields to 128. The interface does not allow to increase this value so we had to redefine bits of HTTP::Methods in a very ugly way. The part that reads the HTTP response-header from the network is buggy. LWP is doing the right thing for the body interestingly enough. Again, we had to redefine one of libwww's method to work around this. Finally, HTTP::Message::parse() is broken in that it does not understand header-fields with multiple values. This is bizarre because a request with multi-valued headers (via push_header()) is correctly stringified into an HTTP request.
By and large, our impression is that libwww-perl works well for most of the common cases. Stretch it a little, though, and you'll soon find it to be a less agreeable companion.
This is an outrageously bad module and I implore everyone to have a look at its source code. The shuffle() function takes over half a minute to shuffle a list of 1000 elements. I did some metrics: In order to do the shuffling, it did no less than 8500 full iterations over the input list! in_array() is just plain broken and only works by accident. Again, I recommend a look at the source code for the sake of amusement. Almost all other functions are implemented in an extremely awkward manner at best, suggesting that its author is not familiar with Perl.
I originally gave this module an undeserved bad rating because I was too stupid to use it properly.
When used right, it does its job in a straight-forward and non-intrusive manner. It spares a module author the annoyance of having to maintain a separate README (or any other) file. Everything can now be derived from one source of POD which makes it easier to keep the various files of a module in sync.
This module comes in extremely handy if you need to present data in tabular form. This doesn't happen all the time but when it does you're really lucky to have Text::Table around becausing laying out tables properly with correct alignment and padding isn't as easy as it seems.
On the function front, this module is flawless. I haven't yet encountered any bad layout artefacts caused by pathological input data. It's also fairly easy and convenient to use when you are willing to accept the default layout.
It's a bit more difficult to use when you want to customize your tables. This is not so much due to its interface but rather because the documentation is organized in a way that will make more than one skim through it necessary. The docs do try to be thorough and don't skimp on explaining things, though.
If it weren't for its documentation, this module should get five stars. A valuable addition to the CPAN.
This module shouldn't exist. The List:: namespace is already cram-packed with modules where the functionality of this one could have easily been merged in. Other than that, I think it's bad style to chose a namespace that it identical to that of an already existing module and only differs in the presence or absence of a plural 's'.
Unfortunately, its author did not respond to my email either.
Superfluous, boastful and vain. The first sentence in the PODs is just plain off: "I have just released my 100th module to CPAN, the first time that anyone has reached that target."
Personally, I don't see the achievement in that. Only a fraction of those modules was thought out well enough to justify a CPAN release. Other than that, it stands to reason that it's not possible to maintain and give support for that many modules. If you don't do that, you haven't released a module. You've just thrown some code out into public.
Considering the rather depressing situation with Perl modules handling ogg-vorbis, this is one of the better modules in that it at least works.
However, its documentation is in parts inaccurate or even wrong. In order to understand how to retrieve the tags, I eventually had to look into the module's test-script. It turns out that Ogg::Vorbis::Header::comment() doesn't return a list of values (as advertized by the documentation) but rather an array which makes quite a difference in scalar context.
As for the test-script, it contains some rather questionable constructs. Also, it's not portable.
If I were to name the most ingenious CPAN module, then I'd not hesitate to name Tk.
All the pitfalls of Tk (such as failing tests on installation, slightly scattered documentation, complexity in usage) are by far outweighted by its immens power and flexibility.
Each time I have to do something involving Tk, I have to find my way through the many classes. However, once I have identified which things I need and how they interact with each other, the programming itself is pure joy. In the end you just need a few lines of code to create an extremely powerful application.
If you are hacking on the Perl source, this distribution makes it extremely easy to create proper patches to send to the porters.
The idea is to create a copy of the source tree, make changes in one of them (possibly involving many files) and then run the 'makepatch' script on those two directories. It will take care of everything and you no longer have to worry whether you might have forgotten a file in your patch.
This is a niche-module in that its target group is those people who hack the source of perl. The supplied script "buildaperl" takes a patch-number or version and builds the respective Perl distribution. It can thus be used to find out which patch can be blamed for a particular change. This module is indispensable for every perl porter.
The only drawback is that you will most likely need the full Perl repository with all changes. This repository is currently around 700meg in size. This repository is worth every single byte though.
Another premature upload to the CPAN without any documentation or tests.
The Makefile does not list any of the prerequisites. The source itself relies on Kolab::Util which nowhere exists. This means that it cannot even theoretically run anywhere.
Hilarious! The point of not putting it under the Acme:: namespace should be obvious. When reading the PODs for the first time, you really think this is serious. The namespace Acme::SuperPython would spoil this.
Mark, thanks for a great parody!
Just like any module should be: Doing a single job very well. The interface couldn't be simpler and it's well documented. It's also the only module around that can be used to programmatically syntax-color sourcecode of virtually every language (well, of those that vim can handle which are quite many).
Downsides are its speed (this is vim's fault however) and some problems when interrupting a running script with ctrl+c or so (some vim instances will keep on running and eat a lot of CPU). Nonetheless, this is a real CPAN-jewel.
*sigh* When will people stop uploading incomplete modules? Complete means documentation and proper tests. This distribution fails in both respects.
Also, it appears to unpack into the wrong directory. A module with this name should unpack into "Log-Easy-0.01/Log" and not "Log-Easy-0.01/Easy".
Spamassassin has rightly gained its faim. Since everybody knows it. there's not much to say about it.
However, it's not perfect. The newest plague of W32.Gibe/Swem has shown that it's no run-and-forget solution. It has serious problems with large amount of Mails, even when using the spamd/spamc combo. As a rule of thumb: If you can filter out a large amount of mails with plain procmail rules, better do so and not let SA inspect these mails.
A good thing is that more and more mail-servers are tagging Mails with this module. That way there is less need to run it locally and enjoy the luxury of getting already tagged mails.
I chose to rate this module, but it serves as a placeholder for any addition to the CPAN that has been done under the PAUSE-ID SOFTDIA.
It's pointless to a stupendous extent. The module essentially duplicates the functionality of require() wrapped in a BLOCk-eval. Why I would need this if I can achieve the same thing in two or three lines of Perl code escapes me.
Furthermore, the author seems to be pretty clueless about CPAN moduling conventions. Each of his modules comes with an additional documentation-only module explaining in depth all those boring things a user is not interested in. Also, each module seems to contain its prerequesite modules which defeats the purpose of having modules at all.
Sorry for the harsh tone in this rating but all these modules are just a painful waste of the ressources offered by the venerable CPAN.
The only shortcoming of this module is probably it's confusing name which may people distract from what it does.
Feed it C code (of any complexity, it has its own yacc grammar), request a particular structure from it and pack or unpack data according to the struct. That's what the module does.
That way, reading a wav header into a hash for instance becomes a one-liner if you have the C struct. If you already have C code, this module is much more powerful than Perl's built-in pack() and unpack(). It's also faster and very configurable.
This module is really a little revolution to Perl5 and has been heatedly discussed as such among the perl5-porters. It lets you treat everything as an object and thus makes Perl5 look very much like Ruby (or rather any language in which primitive types are objects).
The only drawback is that you need perl-5.8.1RC4 and to apply the enclosed patch against the source-tree. So essentially you have to compile your own Perl.
However, I haven't had so much fun with Perl for a long time. Once it makes it into the core (Perl5.10 is a candidate) a whole new branch of modules will probably make it to the CPAN.
This is IMO the best available module when you actually want to write your own MP3 player. Being sick of mpg123 and its lack of playlist handling capabilities, I wrote my own console player with the help of this module and have been using it exclusively for over one year. It even offers such goodies as an equalizer which - when used moderately - makes the sound brighter and crisper.
Unfortunately, the module relies on the xaudio-sdk which requires registration for a license (although it is free for non-commercial use, I think). I still have an old version of it back from those times, where no such step was necessary and am very careful not to delete it.