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

[Adam D. Ruppe]

On Wednesday, 27 November 2013 at 00:49:57 UTC, H. S. Teoh wrote:
> Sounds like the perfect job for a quick-n-dirty D program, 
> right?

Oh yeah, my http.d and dom.d can make short work of that. I had a 
similar problem last year and ended up getting it to work very 
easily (well, that one used my curl.d, but http.d does cookies 
too now).

> coding, I ran into a blocker: std.net.curl didn't let me specify
> Content-Type of POST requests!!!

.....holy crap, you're not kidding. I thought addRequestHeader 
can do it, but that duplicates the header. Unbelievable.

My curl.d is an ugly piece of garbage. Seriously, I hate it, just 
look at this signature:

string curlAuth(string url, string data = null, string username = 
null, string password = null, string contentType = 
"application/x-www-form-urlencoded", string methodOverride = 
null, string[] customHeaders = null, string cookieJar = null) {

but at least it gets the job done - I use it on my work projects 
to access all kinds of things from arbitrary website downloads 
(one of the work sites offers a link posting functionality 
similar to Facebook, it downloads the site and reads description, 
images, etc. to make a richer link preview) to a variety of APIs 
like bing search, Facebook, twitter, linkedin, youtube, 
Authorize.net, I've done a lot with it, and especially my helper 
oauth.d file for many of them, all built on top of this hideous 
do-it-all function.

If I was doing a whole new interface, I think I'd prefer to do an 
object that keeps this state internally. So it'd be like:

auto client = new HttpClient("host", port);
client.userAgent = "whatever";
// authorization would ideally be a UFCS function or at least do 
some template method check, so it can be extended by things like 
oauth
client.authorization = BasicAuth("username", "password");

client.host = "host override if you want.com";

auto response = client.post("/login", ["username":"lol", 
"password":"rofl"]);

// or
client.post("/login", "text/plain", "text");

// or
client.post("/login", "text/xml", someXmlInputRange);

or something like that. Url and method could be set via 
properties too; get, post, head, put, delete, and so on could 
perhaps be implemented in terms of opDispatch that sets the 
properties then calls .execute();


Anyway, the important thing would be if you do future changes to 
this object, it maintains a bit of state. Cookies and such. That 
could work with async too, since the response returned would be 
more like a handle, so you then do

response.wait();

or do callbacks or whatever.


But the point is it'd be nice and simple for most series of 
requests.