Re: [MirageOS-devel] conduit + vchan

[Dave Scott <Dave.Scott@xxxxxxxxxx>]

Hi,

On 1 Sep 2014, at 08:33, Anil Madhavapeddy <anil@xxxxxxxxxx> wrote:

> 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

Great, this repo is working for me. I’ve added the latest, greatest vchan 
library— I’d like to get that working with conduit too.

> 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.
> 
> I'm tracking the overall feature in : 
> https://github.com/mirage/mirage/issues/287
> 
> 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.

Sounds good.

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

IIRC we designed the FLOW from scratch and it ended up different to TCPv4. 
Since we wanted V1 to remain stable I think it made sense to postpone 
TCPv4-as-FLOW to V2. It’s definitely the right time to fix it now though! That 
reminds me, I wanted to make CONSOLE into a superset of FLOW also.

Cheers,
Dave

> 
> -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.
>> 
>> https://github.com/mirage/mirage-www/pull/219/files#diff-ad18f4983a07ffe4c757b33c537226a1R70
>> 
>> 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:
>> 
>> https://github.com/djs55/ocaml-vchan/blob/improve-lwt/lwt/vchan_lwt_unix.ml
>> 
>> 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
> 
> _______________________________________________
> MirageOS-devel mailing list
> MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel


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