[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MirageOS-devel] Cohttp/Conduit refactoring update

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.


MirageOS-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.