On 28 May 2014, at 02:08, Rudi Grinberg <rudi.grinberg@xxxxxxxxx> wrote:
> On Tue, 27 May 2014 17:11:45 -0400, Anil Madhavapeddy <anil@xxxxxxxxxx> wrote:
>
>> Interesting -- I'd envisioned all that logic going into Conduit instead of Cohttp itself. The issue with Cohttp having all this logic is that it can't be re-used easily by other protocol implementations, and it also ties knowledge of IPv{4,6} into the HTTP library. I believe Jon Ludlam has some patches to send HTTP requests over shared memory vchan, which would be difficult if Cohttp.Connection needs to be extended to know about it. Similarly, Arjun Guha submitted a domain socket mode so that he can communicate with the Docker API via Cohttp: https://github.com/mirage/ocaml-conduit/pull/3
>>
>> With the Conduit patch, all this would be in that library instead. Romain, do you have an Ocsigen working tree with your Conduit patch in that I can take a look at?
>
> I see. Reviewing the changes in conduit currently. That does seem like it would work much better.
Although it does make me wonder what the purpose of Cohttp.Connection really is. To be useful, it still needs a tie back to the underlying Conduit, but also some info about which pipelined request it actually is.
>
>>
>> (re: pre and post 1.0 , the only patch I think needs to be deferred is the completion of the module types from Lwt and Async moving out. The rest are all still pre 1.0 in my mind -- do you agree?)
>
> That's fine with me. But note that we don't have to break any compatibility if we don't want to. We can always leave aliases to module signatures where they used to be. At least this was my plan originally.
Good point -- that would indeed avoid needless breakage.
-anil
