Re: [MirageOS-devel] conduit + vchan

[Anil Madhavapeddy <anil@xxxxxxxxxx>]

On 1 Sep 2014, at 21:43, Dave Scott <Dave.Scott@xxxxxxxxxx> wrote:

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

Excellent!  I'll cut a minor Cohttp release with some important bugfixes from a 
branch, so we have time to get this working.  If you get a chance to review the 
Conduit APIs, I'll merge to mirage/master branches rather than have them on my 
personal forks.

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

This will definitely be V2 I think -- since end points in Conduit are abstract, 
we need the sexp accessors for logging endpoints in a human readable format.

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