Re: [MirageOS-devel] Generic use of cohttp

[Anil Madhavapeddy <anil@xxxxxxxxxx>]

On 3 Jan 2015, at 16:49, Christophe Troestler 
<Christophe.Troestler@xxxxxxxxxxx> wrote:
> 
> On Mon, 29 Dec 2014 00:55:43 +0100, Christophe Troestler wrote:
>> 
>> I'd like to build a library on top of cohttp that communicates with a
>> REST API using the Client module with an SSL endpoint.  [...]
> 
> Hi Anil,
> 
> Never mind, I finally decided not to use async â for now at least.  I
> case you are wondering what this is about, I started a binding to the
> Dropbox API <https://github.com/Chris00/ocaml-dropbox> which should be
> usable from Mirage â still have to figure that out though.  The goal
> is to have some students finish it.  Maybe I'll try to develop a
> free/libre client on top of it â that would not hurt IMHO.  Also an
> application to exchange data between Irmin & Dropbox would be nice â
> and a bridge to ease people to switch to new tools.

(Just discovered the followup to my previous reply).

This is very cool!  From a quick look, it appears that if you functorise
over Cohttp_lwt instead of Cohttp_lwt_unix, you will have the desired
Mirage functionality.  We're almost ready to integrate the TLS stack
into the Xen backend (aimed for Mirage 2.5.0), at which point we should
be able to test out the Dropbox bindings as a unikernel.

In the meanwhile, they can be tested on the Mirage Unix backend via the
tuntap module with userspace networking, or via sockets.

> 
> P.S. BTW, why Cohttp_lwt_body instead of Cohttp_lwt.Body ?  That would
> be more in sync with Cohttp.Body IMHO.  More documentation of cohttp
> would be welcome BTW â in particular, the description in OPAM should
> be duplicated at the top of the documentation (it was not clear
> reading it how to activate SSL and what happens if it is not
> present).  I also think a way to check (from cohttp) whether SSL is
> available would be nice.

Indeed.  I'd very much appreciate if you could create issues for any
such comments on https://github.com/mirage/ocaml-cohttp/issues

In particular, functionality such as the availability of SSL should
be very easy to put in.

> 
> P.P.S. For the above library I also need to parse dates.  Instead of
> duplicating another date parsing library in Syndic and in Dropbox, how
> about to make a new one split in sub-modules according to the
> available resources (unix, mirage, javascript)?  I should go under the
> ocaml/ umbrella on Github and aim to become the standard hub for dates
> (modules to convert back and forth from the existing ones should be
> provided).  What du you think?

A date library would be very useful indeed.  There seem to be quite
a few options available already though...?

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