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. - Jonathan M Davis
