After some discussion with Kazu, I'm planning on starting work on a new package called http-client. The goal will be to separate out the core functionality from http-conduit into a lower-dependency package. In particular, I'm hoping to get a package without dependencies on tls, conduit, or resourcet. The motivations for this are: * Kazu and I need a lighter-weight library for testing out Warp. * With WAI 2.0 coming out, the resourcet-dependent interface of http-conduit currently doesn't make as much sense. * By separating things out like this, I believe we can get clean things up. * The vast majority of the http-conduit codebase has nothing at all to do with TLS or conduit support. Persistent connections, cookie handling, multipart forms, chunking, etc, all fall purely into the realm of raw HTTP support. By getting these core features out there separately, people will be able to take advantage of them without reinventing the wheel. Is there any interest from others in this project? If so, please let me know, as specific requests can help guide the API decisions I make.
On Fri, Oct 04, 2013 at 04:48:04AM +0200, Michael Snoyman wrote:
After some discussion with Kazu, I'm planning on starting work on a new package called http-client. The goal will be to separate out the core functionality from http-conduit into a lower-dependency package. In particular, I'm hoping to get a package without dependencies on tls, conduit, or resourcet. The motivations for this are:
* Kazu and I need a lighter-weight library for testing out Warp. * With WAI 2.0 coming out, the resourcet-dependent interface of http-conduit currently doesn't make as much sense. * By separating things out like this, I believe we can get clean things up. * The vast majority of the http-conduit codebase has nothing at all to do with TLS or conduit support. Persistent connections, cookie handling, multipart forms, chunking, etc, all fall purely into the realm of raw HTTP support. By getting these core features out there separately, people will be able to take advantage of them without reinventing the wheel.
Is there any interest from others in this project? If so, please let me know, as specific requests can help guide the API decisions I make.
I'd love to have an alternative to http-conduit with fewer dependencies. However, for me the main reason to go with http-conduit instead of HTTP is support for TLS. Not sure what the solution here is. I guess ideally GHC or network would provide SSL/TLS support by relying on OS libraries. Cheers, Simon
participants (2)
-
Michael Snoyman -
Simon Hengel