Deprecate in favor of Requests.jl? about httpclient.jl HOT 11 OPEN

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 [email protected]
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
#21 (comment)
.

from httpclient.jl.

Problem on my end; apologies!

from httpclient.jl.

No worries.

On Sat, Aug 29, 2015 at 12:58 PM, Sebastian Good [email protected]
wrote:

Problem on my end; apologies!

—
Reply to this email directly or view it on GitHub
#21 (comment)
.

from httpclient.jl.

Please see open thread at JuliaWeb/Roadmap#1 (comment)

from httpclient.jl.

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

from httpclient.jl.

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.

from httpclient.jl.

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.

from httpclient.jl.

Ya that makes sense.

On Thu, Sep 3, 2015 at 2:35 PM, Jacob Quinn [email protected]
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
#21 (comment)
.

from httpclient.jl.

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:

• HTTPClient.jl as a lightweight HTTP client package which, based on the user's preference via an argument, either uses libcurl or Julia's streams implementation internally.
• Requests.jl as a more high-level package which requires HTTPClient.jl for HTTP interaction but in addition uses http-parser + additional tools to process the data received by the client.

Advantages:

• No renaming of packages is necessary.
• HTTPClient.jl would be a lightweight entry point for users looking just for an HTTP client. No confusions about its functionality or naming.
• If there is demand/capacity, a full Julia reimplementation of libcurl can be integrated under the hood over time. In the meantime, users can either choose the curl-way with all its functionality or just use the Julia stream-based HTTP interaction.
• Requests.jl can be developed further into a more advanced high-level package which is similar to python's Requests package or R's httr package providing users an easy way to scrape data from the web.

Disadvantages:

• Rewriting/Moving some code from Requests.jl to HTTPClient.jl. Also this means the basic HTTP verbs will not be offered by the Requests.jl interface as they are now.
• Extending HTTPClient.jl in a way such that the user can choose between the curl-way and the julia-way.
• Extending HTTPClient.jls HTTP verbs such that all functionality currently provided by Request.jl is still provided.

What do you think?

from httpclient.jl.

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.

from httpclient.jl.

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.

from httpclient.jl.