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
