Hi Dave,
The conduit merge required quite a few different patches across repositories, so I've opened up an OPAM remote to track all the branches required here: https://github.com/mirage/mirage-dev
There's a Travis file to check that the overall set of packages are working. Since it's a sequence of git remotes, we'll need to occasionally push dummy commits to the mirage-dev repository to trigger a recompile with the latest sub-repositories.
So far, the Conduit API is settling down and works with Lwt_unix, Async and Mirage, including client DNS lookups and HTTP requests. Before merging, I'd like to:
- add sexp accessor functions - switch to V2 interfaces (required for previous) - get OCaml TLS hooked in
Once this is all done, Conduit can be released independently of the rest of the Mirage libs (which in turn unblocks a Cohttp 1.0 release). I'm just holding back releasing it too early so that we don't have to keep revving the Lwt_unix interfaces all the time.
Regarding vchan, the biggest difference in the new APIs is that Conduit creates a V1_FLOW interface that abstracts across all the connection mechanisms (currently TCPv4 and vchan). Previously in Mirage 1.0, this was hardcoded to TCPv4, and I've had to modify those interfaces in the development repository to bring TCPv4 in compliance with the FLOW interface (it's slightly odd that we didn't do that before!).
-anil
On 23 Aug 2014, at 00:43, David Scott <scott.dj@xxxxxxxxx> wrote:
In the last weekly call I agreed to work on conduit + vchan.
Looking at the Lwt_unix conduit API
https://github.com/avsm/ocaml-conduit/blob/v0.6/lib/lwt_unix_conduit.ml
It seems to be using Lwt_io input/output channels. So my plan is to implement Lwt_io channels on top of the FLOW exposed by vchan. I've got a prototype of that here:
Does this general approach seem sensible? Since the conduit code is quite new and under heavy development I thought I'd better ask :-)
A side-benefit is that Lwt_unix apps which use vchan can decide to use either the Mirage FLOW interface or the Lwt_io interface.
It looks like the Mirage conduit interface is FLOW based, so I can expose the existing vchan implementation there.
Cheers, -- Dave Scott
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
| 
