Should "std.net.curl" be moved from Phobos to Deimos?

[Adam D. Ruppe]

On Tuesday, 26 November 2013 at 23:05:08 UTC, Andrei Alexandrescu 
wrote:
> That's quite a claim to make.

If you've used HTTP, you'll know how true it is. Indeed, since a 
request consists solely of a request and a body, being able to 
change them by definition gives you full access!

The most complex things in http are proxying and caching. curl 
does proxying, wich my 300 line http.d doesn't do. As far as I 
know, curl doesn't do caching at all. (My curl.d offers a cache 
functionality on top of curl, but it ignores the http headers, 
instead opting simply for a max age provided by the programmer, 
e.g. "refresh cache if the file is more than four hours old or 
doesn't exist, otherwise just return the cache file's contents".)

> but from what I see at http://curl.haxx.se/changes.html it 
> seems to me like a hard working professional is responding to 
> real bug reports and feature requests from the field

Yet, very little of that stuff is actually exposed through 
std.net.curl anyway, except perhaps through the download() and 
upload() functions. Phobos doesn't directly expose tftp, imap, 
pop, globbing, ntlm, nor most of the other things mentioned on 
that changelog.

SSL is legitimately a bit of a pain, but curl doesn't actually 
implement ssl, it just uses it, with a few different backends - 
openssl, gnutls, and so forth. Indeed, this is one of the 
difficulties in using curl with D, it is compiled with openssl 
but the client machine uses gnutls or whatever. We'd have that 
same problem.

Async requests are similar to ssl: it should implemented in a 
generic way for all I/O, then the http layer can just use that. 
It's probably just a matter of time before there's demand for an 
async file and socket facility in there anyway.


Again though, my position is that curl is ok and I use it myself, 
but let's not assume we need the entire kitchen sink that curl 
offers, especially given the fact that std.net.curl barely 
scratches it anyway. If someone does need one of curl's less 
common features, it is still there for them, but for the 99% we 
can do with the std.net.curl api, I'm sure we could make that 
happen in ~1000 lines of curl replacement.