Closed FGasper closed 8 years ago
I looked at HTTP::Tiny when you mentioned it a few weeks back. Though it looked fully serviceable I decided to stick with LWP::UserAgent. I feel that LWP is so common that its inclusion is ‘standard’. That said, if there are common environments that cannot handle it or make it challenging to do so, and HTTP::Tiny fills the gap, then I am very happy to consider it as an alternative. I think it has to be a somewhat compelling case to prompt a change though.
I think I mistakenly remove the ua parameter from the documentation. It is there still, but not in the doc. The intention there is to pass in a LWP::UserAgent object that has whatever customization that the caller desires.
-stephen
From: FGasper notifications@github.com Reply-To: sludin/Protocol-ACME reply@reply.github.com Date: Monday, January 11, 2016 at 7:55 PM To: sludin/Protocol-ACME Protocol-ACME@noreply.github.com Subject: [Protocol-ACME] use_http_tiny (#8)
Hi Stephen,
Is P::A meant to accept the “ua” parameter publicly, or was that just for testing?
Anyway, use_http_tiny (on my fork) is a branch that uses HTTP::Tiny This looks a much “slimmer” fit for what you want than LWP
Ideally, IMO, it would use HTTP::Tiny::UA, but that has more dependencies for the OO interface that don’t seem worth pulling in if this is just for internals If, though, you’re exposing the “ua” parameter and documenting it, IMO it makes sense to support all three object types
Anyway I have not tested this, so no pull request yet Just want to clear the idea with you before I run with it
— Reply to this email directly or view it on GitHub.
On 12 Jan 2016 12:35 AM, Stephen Ludin wrote:
I looked at HTTP::Tiny when you mentioned it a few weeks back. Though it looked fully serviceable I decided to stick with LWP::UserAgent. I feel that LWP is so common that its inclusion is ‘standard’. That said, if there are common environments that cannot handle it or make it challenging to do so, and HTTP::Tiny fills the gap, then I am very happy to consider it as an alternative. I think it has to be a somewhat compelling case to prompt a change though.
HTTP::Tiny is core in 5.14 … so it’s actually more widespread than LWP at this point except for old (pre-2012) Perl versions.
LWP is not core. I don’t think it ever has been. Systems that don’t have it have quite a large dependency tree to download if they want to get P::A to work … which will frustrate those who don’t have LWP installed--especially if they look at the code and see how simple the HTTP need really is!
By contrast, people who don’t have HTTP::Tiny only need to install a single module with no non-core dependencies. They’re already running an unsupported Perl versions, of course.
What do you think?
-FG
I did not realize H::T was core.
Sold. I'll do the switch so I get some practical experience with it.
-stephen
On Jan 11, 2016, at 21:48, FGasper notifications@github.com wrote:
On 12 Jan 2016 12:35 AM, Stephen Ludin wrote:
I looked at HTTP::Tiny when you mentioned it a few weeks back. Though it looked fully serviceable I decided to stick with LWP::UserAgent. I feel that LWP is so common that its inclusion is ‘standard’. That said, if there are common environments that cannot handle it or make it challenging to do so, and HTTP::Tiny fills the gap, then I am very happy to consider it as an alternative. I think it has to be a somewhat compelling case to prompt a change though.
HTTP::Tiny is core in 5.14 … so it’s actually more widespread than LWP at this point except for old (pre-2012) Perl versions.
LWP is not core. I don’t think it ever has been. Systems that don’t have it have quite a large dependency tree to download if they want to get P::A to work … which will frustrate those who don’t have LWP installed--especially if they look at the code and see how simple the HTTP need really is!
By contrast, people who don’t have HTTP::Tiny only need to install a single module with no non-core dependencies. They’re already running an unsupported Perl versions, of course.
What do you think?
-FG
— Reply to this email directly or view it on GitHub.
Cool! Thank you. :)
-F
On 12 Jan 2016 10:04 AM, Stephen Ludin wrote:
I did not realize H::T was core.
Sold. I'll do the switch so I get some practical experience with it.
-stephen
On Jan 11, 2016, at 21:48, FGasper notifications@github.com wrote:
On 12 Jan 2016 12:35 AM, Stephen Ludin wrote:
I looked at HTTP::Tiny when you mentioned it a few weeks back. Though it looked fully serviceable I decided to stick with LWP::UserAgent. I feel that LWP is so common that its inclusion is ‘standard’. That said, if there are common environments that cannot handle it or make it challenging to do so, and HTTP::Tiny fills the gap, then I am very happy to consider it as an alternative. I think it has to be a somewhat compelling case to prompt a change though.
HTTP::Tiny is core in 5.14 … so it’s actually more widespread than LWP at this point except for old (pre-2012) Perl versions.
LWP is not core. I don’t think it ever has been. Systems that don’t have it have quite a large dependency tree to download if they want to get P::A to work … which will frustrate those who don’t have LWP installed--especially if they look at the code and see how simple the HTTP need really is!
By contrast, people who don’t have HTTP::Tiny only need to install a single module with no non-core dependencies. They’re already running an unsupported Perl versions, of course.
What do you think?
-FG
— Reply to this email directly or view it on GitHub.
— Reply to this email directly or view it on GitHub https://github.com/sludin/Protocol-ACME/issues/8#issuecomment-170940681.
Transition to HTTP::Tiny in v0.08
Hi Stephen,
Is P::A meant to accept the “ua” parameter publicly, or was that just for testing?
Anyway, use_http_tiny (on my fork) is a branch that uses HTTP::Tiny. This looks a much “slimmer” fit for what you want than LWP.
Ideally, IMO, it would use HTTP::Tiny::UA, but that has more dependencies for the OO interface that don’t seem worth pulling in if this is just for internals. If, though, you’re exposing the “ua” parameter and documenting it, IMO it makes sense to support all three object types.
Anyway. I have not tested this, so no pull request yet. Just want to clear the idea with you before I run with it.