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

["Rudi Grinberg" <rudi.grinberg@xxxxxxxxx>]

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