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

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

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.


- 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...


MirageOS-devel mailing list



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