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

[Jonas Drewsen]

On Wednesday, 27 November 2013 at 01:32:18 UTC, Jonathan M Davis 
wrote:
> On Wednesday, November 27, 2013 02:05:39 Adam D. Ruppe wrote:
>> ...unless doing a new interface is on the table too. Then, we 
>> can
>> leave std.net.curl exactly how it is, so people who use it 
>> don't
>> have broken code, while a new std.net.http, std.net.smtp,
>> std.net.ftp, and so on are phased in for people who want them. 
>> I
>> could get behind that.
>
> If we were going to replace std.net.curl, I would fully expect 
> us to end up
> with a new API, because the current API is what is beacuse of 
> what curl can
> and can't do rather than because it's the best API for what 
> you're
> conceptually trying to do. The new API might end up being 
> fairly close to the
> current one, but I would not consider it desirable to try and 
> maintain a 100%
> compatible API if we were replacing the current implementation 
> except in cases
> where the current API is the best choice even without curl 
> underneath it.
> Maybe that would be most of the API, but I'd hate to see us put 
> ourselves in a
> straightjacket based on how curl works when writing an API 
> which didn't depend
> on curl - particularly as writing our own would give us the 
> opportunity to
> make sure that we had something that made the most conceptual 
> sense rather
> than necessarily having what curl has.

I definitely agree. In addition D has obtained some nice features 
since the definition of the std.net.curl API that I would liked 
have used back then.

I do believe that people underestimate the work needed to make a 
proper http client implementation with the bells and whristles 
that people expect like cookie store, chuncked transfers, ssl, 
authentication... and handle wierd per server type bugs as well.

I definitely think that a native solution is the end goal here. 
But if that is the case then it should be based on a proper event 
based system (std.event?) to support async handling (peek at how 
vibe has done it very nicely). But that in turn depends somewhat 
on allocators being well defined and implemented as I see it.

-Jonas