Skip Menu |
 

This queue is for tickets about the Net-HTTP-Tiny CPAN distribution.

Report information
The Basics
Id: 75982
Status: resolved
Priority: 0/
Queue: Net-HTTP-Tiny

People
Owner: Nobody in particular
Requestors: XSAWYERX [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: Wishlist
Broken in: (no value)
Fixed in: (no value)



Subject: A "Why" section, or comparison
Download (untitled) / with headers
text/plain 425b
While you mention HTTP::Tiny in the POD, it's still unclear why this module was written. Was HTTP::Tiny lacking something? Does it have any incompatibilities that are important to you? Perhaps these considerations would be important to others. Could you maybe share whatever prompted you to write your own tiny HTTP client? I would surely appreciate it. :) (then again, if you don't want to, feel free to close this ticket)
Subject: Re: [rt.cpan.org #75982] A "Why" section, or comparison
Date: Thu, 22 Mar 2012 19:33:34 +0000
To: Sawyer X via RT <bug-Net-HTTP-Tiny [...] rt.cpan.org>
From: Zefram <zefram [...] fysh.org>
Download (untitled) / with headers
text/plain 2.4k
Sawyer X via RT wrote: Show quoted text
>While you mention HTTP::Tiny in the POD, it's still unclear why this >module was written. Was HTTP::Tiny lacking something?
HTTP::Tiny, like all the other HTTP clients on CPAN, has an awkward interface, in that the caller has to explicitly check for errors. I wanted something that I could use without usually having to write any extra code for the error case. Actually I wouldn't have written Net::HTTP::Tiny as an isolated project. It was an afterthought following Net::FTP::Tiny. Previously I'd done FTP using either LWP or Net::FTP. LWP is of course very heavy, and has Perl-version portability issues, so I wanted something reasonably light and portable. Net::FTP is better in those respects, but hideous to drive for the simple case: creating the connection, changing directory, setting mode, and so on, all have to be done explicitly in procedural code, each with their own error checking. I wanted something that could be driven from a URL, as LWP can be. Hence Net::FTP::Tiny: lightweight (much lighter even than Net::FTP) and with URL-based control. Once I was writing that, I was inclined to make it nice in other ways. I made it signal errors as exceptions, unlike both LWP and Net::FTP. I made the error messages stylistically consistent and consistently useful, which is an area where Net::FTP lacks. I made it IPv6 capable, unlike Net::FTP (and LWP uses Net::FTP underneath so suffers the same problem). So having written that, I realised that although the original motivations behind it didn't apply to HTTP, I'd rather like to have those ancillary benefits with HTTP. So I wrote Net::HTTP::Tiny with a parallel structure (much of the URL-parsing code is just copied across). Its wins relative to HTTP::Tiny are errors as exceptions, consistent error messages, and IPv6 capability. It's also slightly tinier than HTTP::Tiny, but not enough to make a selling point in itself. But I don't really want to advertise this in the documentation. It would be painfully close to a rant, and would appear to be denigrating HTTP::Tiny, which I don't want to do. HTTP::Tiny is a nice module for its intended use cases. I link to it as a "see also" on the basis that it's the next module you should turn to if Net::HTTP::Tiny doesn't have enough power, for example if you need to do a POST. The semantics of the other two "see also"s are "lower level" and "same thing for a different protocol". Net::FTP::Tiny has three "see also"s with the same set of relationships. -zefram
Download (untitled) / with headers
text/plain 476b
Thank you for such an extensive explanation. I wasn't expecting a thorough walkthrough of why you've written it, what benefits it has, how it differs from others and why in fact you intentionally did not add it to the documentation. I appreciate it very much, and will now be able to differ between them and will probably use Net::HTTP::Tiny on some occasions while still using HTTP::Tiny for others. (I also like the stories behind how modules are born :) All the best! s.
I don't know why it reopened the ticket. Sorry.


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.