Deprecate in favor of Requests.jl?

[malmaud]

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]

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
#21 (comment)
.

[sebastiang]

Problem on my end; apologies!

[malmaud]

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
#21 (comment)
.

[amitmurthy]

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

[amitmurthy]

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

[tmlbl]

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]

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]

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
#21 (comment)
.

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?

[malmaud]

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]

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.