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

[Anil Madhavapeddy <anil@xxxxxxxxxx>]

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?

(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?)

-anil

On 27 May 2014, at 16:48, Rudi Grinberg <rudi.grinberg@xxxxxxxxx> wrote:

> What about this patch: https://github.com/mirage/ocaml-cohttp/pull/143 ?
> 
> It probably has to be updated because of your latest conduit changes. I'd 
> like to know whether it's scheduled for pre or post 1.0?
> 
> 
> On Tue, 27 May 2014 06:10:33 -0400, Anil Madhavapeddy <anil@xxxxxxxxxx> wrote:
> 
>> There are a number of patches queued up to Conduit/Cohttp that I've been 
>> looking at this morning, and thought I'd give an update on their integration.
>> 
>> First, a quick recap on the libraries:
>> 
>> - Conduit can be considered as the 'polymorphic sockaddr' library that 
>> exposes all the various mechanisms to connect from A to B.  This includes 
>> the traditional mechanisms such as TCP, but also adds SSL+TCP, shared memory 
>> and vchan.  Its build system uses optcomp to not have hard dependencies on 
>> some of the mechanisms such as vchan, so it can remain a fairly lightweight 
>> library.
>> 
>> - Cohttp is the implementation of HTTP, functorized across 
>> Lwt/Async/Unix/Mirage.  It uses Conduit for all its connectivity needs.
>> 
>> Updates:
>> 
>> - Rudi submitted a nice patchset to pull out all the Cohttp module types 
>> into one file that acts as the library documentation.  This unfortunately is 
>> not OASIS compatible since it requires the definition of the same module 
>> name inside multiple packs, which requires a staged build (OASIS currently 
>> builds the pack file in the same directory as the submodules, and so the 
>> internal modules are also exposed to other libraries).
>> 
>> I'm going to put this refactoring on ice until post-Cohttp-1.0, as it's a 
>> significant rewrite.  For the interested, I have branches on 
>> avsm/ocaml-cohttp with various build system changes, and none of them are 
>> ideal.  My next experiment here will be with a Makefile and Jenga 
>> (separately).
>> 
>> - Arjun Guha has sent in a Conduit patchset to support Unix domain sockets.  
>> I'm changing the Conduit interface (in 
>> avsm/ocaml-conduit#refactor-interface) to encode all the connection 
>> parameters in the polymorphic variant to Conduit.Client.connect.  This lets 
>> us expand it to vchan as well, which I'd like to do before the Xen hackathon 
>> on Friday as a nice demonstration.  Jon: do you have time to help 
>> integrate/test vchan during the hackathon on Thursday?
>> 
>> - I've also modified Conduit to have a state descriptor so you have to 
>> initialize a Conduit instance before using it, which makes it much more 
>> Mirage-friendly.  This is also where we hold the information about *source* 
>> interfaces, so you can spawn multiple Conduits that send their information 
>> from different places.
>> 
>> - Everything has sexp serializers now, pending the release of a new Ipaddr 
>> revision (pull request sent to David to look at).
>> 
>> - I'm still thinking about how to expose the SSL information, and this is a 
>> part of the interface that will change as we integrate the pure SSL stack 
>> from Hannes and David.  The OpenSSL bindings have some annoying dependencies 
>> on filesystem references (for the keys), and the pure stack will be much 
>> more value-oriented to allow passing things in memory rather than forcing a 
>> filesystem dependency.
>> 
>> I'm doing a mass integration at the moment, so expect something in the next 
>> few days unless there's a strong objection to any of this...
>> 
>> -anil
> 


_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel