Are you kidding? Coming up with a new module is cool, not embarrassing. I have the feeeling that this may be very useful to many Perl people everywhere, not just the perlmonks- be sure to submit this to CPAN. If your code does have bugs, you'll might get alot of feedback by email. That's great! This promotes the evolution of your code and great improvements. If everyone kept their code under the roof just because he/she thought it had bugs, we wouldn't have CPAN, the wonderful MySQL dbengine, or Linux (not mentioning perlmonks)! In short, you shouldn't be apologizing- you should be bragging about your cool new module that you submitted to CPAN! Have fun dude! NIfty mod! Congrats! Anyone that does "flame" has obviously never contibuted anything to the world of GPL.

But you shouldn't build on prior art until you understand why the prior art is there.
I suspect (but am waiting for confirmation) that japhy was not aware of the
callback parameter, which would have reduced his program to about half its size,
and then it would have handled proxy servers and all protocols, not just HTTP.

The problem with reinventing things is that you now have two or more incompatible mechanisms to accomplish a task, which dilutes the effort,
and can confuse the marketplace (should I use X or Y interface, since both seem
to be in the CPAN?).

Witness News::NNTPClient, an interesting implementation that
predated Net::NNTP, but is now abandoned. I wrote quite a few
programs using the old interface, but have finally just recently succeeded
in cutting them all over. And I did that because I know that Graham Barr
will be around to update Net::*, but who knows about any efforts to pick
up the other package.

SImilarly, a solution based on top of LWP will very likely continue
to work and get bug fixes, because I know that LWP will continue to be
maintained for some time to come. But if japhy submits his independent
code to the CPAN, will he notice when Gisle updates LWP for a security fix,
and re-implement that? I think not.

So, the code doesn't do as much as LWP, won't be maintained the same way
as LWP, and doesn't leverage off the existing code in any big way. Do you think
I can recommend this little code for any production work? Hardly not.

Now, if japhy writes code that uses the LWP callback, the codesize will be reduced,
everything will play well with proxies and new underlying protocols, and the
chances that the code will be maintained will be greatly increased. Everyone wins.
I encourage japhy to rewrite the code to use the callback, and submit it.
I would not encourage the current code to be submitted.

I will be voting this up. I honestly believe that this
post makes one of the most fundamental points about good
programming technique that I have seen merlyn make. If
you read books on programming you will hear it echoed again
and again in many different ways.

The point is that the key to maintainability is to have each
thing done in one place. You want to avoid using two
parallel efforts. Not only is it duplicated effort, both
originally and ongoing, but it is a significant
maintainance problem.

The easiest route to code-sharing in the short-term is
called cut-and-paste. However if you stay aware of where
your energy is going and work to get to code-sharing through
having any particular task done once in your code-base, you
will find that decision paying you back time after time
again.

For more on this I recommend virtually any classic, starting
with The Pragmatic Programmer because it is not only
classic, but also mentions Perl quite a few times. :-)

There are many issues, but I think that if a few extra lines or a new method will actually in some way promote server efficiency (processing time), then they should be added without question.

Efficient coding doesn't always mean less code. Consider the case where a fundamental method is for some reason missing from the object.

I added a new method to Lady /TM specifically for updating a page counter. To make everything simpler, if the counter wasn't found during a pass through the index, it was added automatically. The previous method of updating a counter in a hash of counters was too slow, requiring an extra recursion through the index. Once to read it. Another to read it again and write the change.

The new method specially developed for this task reads the counter table and holds the entire table, closes the file. Then quickly reopens it for a write access and prints the updated file.

The method is much more efficient than would be an MS-Access ODBC implementation that would require that the large MS-Access driver is loaded. I "reinvented" Lady /TM because I had uses in mind that seemed simple. It seemed obvious that ODBC and MS-Access was over-kill for my immediate application which needed speed.

When I sit next to my server and listen to the MS-Access driver load every now and then I am truly gratified for having "re-invented" Lady /TM.

Went to join the gridlock to see it
Held an eclipse party
Watched a live feed
I cn"t see tge kwubosd to amswr thus
I tried to see it, but 8000 miles of rock got in the way
What eclipse?
Wanted to see it, but they wouldn't reschedule it
Read the book instead