[MirageOS-devel] Cohttp/Conduit refactoring update

[Anil Madhavapeddy <anil@xxxxxxxxxx>]

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