search

JuliaWeb / HTTPClient.jl

DEPRECATED, USE HTTP.jl INSTEAD
https://github.com/JuliaWeb/HTTP.jl
Other
17 stars 16 forks source link

Deprecate in favor of Requests.jl? #21

Open malmaud opened 9 years ago

malmaud commented 9 years ago

Is there something this does that Requests.jl doesn't? If so, I'd prefer to get that functionality into Requests.jl so there is only one canonical HTTP client in JuliaWeb. cc @amitmurthy - looks like you are the primary contributor.

malmaud commented 9 years ago

Requests.jl is supposed to have multi-part data. Do you have a test case that fails?

On Sat, Aug 29, 2015 at 12:53 PM, Sebastian Good notifications@github.com wrote:

this library handles multi-part data while Requests.jl does not seem to. It also handles FTP though that is a bit of an accident of implementation.

— Reply to this email directly or view it on GitHub https://github.com/JuliaWeb/HTTPClient.jl/issues/21#issuecomment-136009151 .

sebastiang commented 9 years ago

Problem on my end; apologies!

malmaud commented 9 years ago

No worries.

On Sat, Aug 29, 2015 at 12:58 PM, Sebastian Good notifications@github.com wrote:

Problem on my end; apologies!

— Reply to this email directly or view it on GitHub https://github.com/JuliaWeb/HTTPClient.jl/issues/21#issuecomment-136009444 .

amitmurthy commented 9 years ago

Please see open thread at https://github.com/JuliaWeb/Roadmap/issues/1#issuecomment-74374590

amitmurthy commented 9 years ago

Can ask this question on Julia Users too - feedback from users of both packages will be useful.

tmlbl commented 9 years ago

I prefer HTTPClient because it is more lightweight -- Requests feels rather slow to compile and use. Also, the last time I tried to work on requests (a month or two ago) it was still not passing tests in 0.4 due to a difficult bug with the multipart file encoding. I would prefer to continue having the option to use a lightweight curl-based HTTP library.

quinnj commented 9 years ago

I think we should just have a Curl.jl library that included the low-level library wrapping + higher-level user interface (i.e. merge this and LibCURL). That way it's distinct from the pure-Julia webstack, yet still available for projects that want.

malmaud commented 9 years ago

Ya that makes sense.

On Thu, Sep 3, 2015 at 2:35 PM, Jacob Quinn notifications@github.com wrote:

I think we should just have a Curl.jl library that included the low-level library wrapping + higher-level user interface (i.e. merge this and LibCURL). That way it's distinct from the pure-Julia webstack, yet still available for projects that want.

— Reply to this email directly or view it on GitHub https://github.com/JuliaWeb/HTTPClient.jl/issues/21#issuecomment-137537132 .

ghost commented 8 years ago

An experience from a new Julia user: I was looking for a HTTP client and initially got quite confused by the various Julia packages around here. It took me time to figure out the differences between Requests.jl and HTTPClient.jl. Generally, I therefore think it would be helpful to differentiate those two packages better and also having one main/general HTTP client for Julia as an entry point/easy starting point for new users. I think it also would be helpful if this package is named accordingly (e.g. HTTPClient.jl) but I understand that renaming existing packages will create quite some confusion.

As far as I understood, Requests.jl's HTTP interaction is based on Julia's internal stream implementation and also includes http-parser whereas HTTPClient.jl uses libcurl internally for HTTP interaction. I agree with @tmlbl and also like @quinnj's suggestion of having a separate Curl.jl but would like to propose another idea/structure:

Advantages:

Disadvantages:

What do you think?

malmaud commented 8 years ago

If someone wanted to take the time to do that, I think it would be great. It's probably not something any of the current maintainers will get around to do doing though.

sgryjp commented 5 years ago

Could you please consider adding some notices of "this package is DEPRECATED", as Requests.jl?

I confirmed that this package does not work on Julia 0.7.0 or newer. Also, a PR to make this runnable on newer Julia is ignored. I believe this is effectively deprecated and putting some notices helps new comers to avoid using this.