Just to chime in, the suggestion to create a client that lives outside of cohttp is also supported by me.
I think the design space for http clients is large enough to support many different libraries. I wouldn’t want to use cohttp’s position to prevent people from experimenting. Aside from that, there’s also the more practical reason that the current maintainers (including me) seem to have a large enough backlog in cohttp without adding designing/implementing/testing an http client to our list. Rudi. On April 26, 2015 at 1:07:14 PM, Trevor Smith ([email protected]) wrote: Hi all, tl;dr I would like to create a more feature-ful and higher level http client library. Should this go into cohttp or be a separate library? I would suggest it is a separate library. I would like to create a higher level http client to work with Async. I would excited to have this support LWT as well if others wanted to do that work. My personal needs at the moment are connection pooling, more sugar for ease of use (think ease of use of Python's Requests http://docs.python-requests.org/en/latest/), much more extensible (think http://www.intridea.com/blog/2012/3/12/faraday-one-http-client-to-rule-them-all). There's other things that one wants in a client library: dealing appropriately with cache headers, cookies and redirect handling that would need to be added at some point. It seems that Cohttp's current interface is low level, and that there's already been discussion suggesting that the complexity of implementing a http client should be part of another library (https://github.com/mirage/ocaml-cohttp/issues/76). I would suggest that I begin work on this new library because it will be quicker to get the details ironed out without taking up the current maintainers time. I would see this library's relationship to Cohttp similar to https://github.com/rgrinberg/opium. There will need to be multiple changes to the current Cohttp Async client to support something like this, but I would try and keep those minimal, with the idea being that Cohttp stays the bedrock of http implementations for both client and servers. If at some point, it made sense to merge the efforts I'd be open to that. Also if the current maintainers feel strongly that this work should all go into Cohttp I am happy to contribute it there. Eager to hear your thoughts. Thanks. Trevor _______________________________________________ MirageOS-devel mailing list [email protected] http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
_______________________________________________ MirageOS-devel mailing list [email protected] http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
