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

["Rudi Grinberg" <rudi.grinberg@xxxxxxxxx>]

On Tue, 27 May 2014 17:11:45 -0400, Anil Madhavapeddy <anil@xxxxxxxxxx>  
wrote:
> Interesting -- I'd envisioned all that logic going into Conduit instead  
> of Cohttp itself.  The issue with Cohttp having all this logic is that  
> it can't be re-used easily by other protocol implementations, and it  
> also ties knowledge of IPv{4,6} into the HTTP library.  I believe Jon  
> Ludlam has some patches to send HTTP requests over shared memory vchan,  
> which would be difficult if Cohttp.Connection needs to be extended to  
> know about it.  Similarly, Arjun Guha submitted a domain socket mode so  
> that he can communicate with the Docker API via Cohttp:  
> https://github.com/mirage/ocaml-conduit/pull/3
> With the Conduit patch, all this would be in that library instead.   
> Romain, do you have an Ocsigen working tree with your Conduit patch in  
> that I can take a look at?
I see. Reviewing the changes in conduit currently. That does seem like it  
would work much better.
> (re: pre and post 1.0 , the only patch I think needs to be deferred is  
> the completion of the module types from Lwt and Async moving out.  The  
> rest are all still pre 1.0 in my mind -- do you agree?)
That's fine with me. But note that we don't have to break any  
compatibility if we don't want to. We can always leave aliases to module  
signatures where they used to be. At least this was my plan originally.
> -anil
>
> On 27 May 2014, at 16:48, Rudi Grinberg <rudi.grinberg@xxxxxxxxx> wrote:
>
> > 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.
> > > 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