Hi Christophe,
IMHO, you shouldnât worry about accommodating async until thereâs some demand for it (and vice versa for lwt if you were an async user). However, I do think that you can make some interface improvements to make it a lot easier for potential async users. Request and Response types are portable between backends in cohttp. Hence exposing them directly would allow async users to make fire off their own requests. But this does have the disadvantage of leaking a larger interface than necessary.
Regards,
Rudi.
On April 19, 2015 at 1:41:35 PM, Anil Madhavapeddy (anil@xxxxxxxxxx) wrote: 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
Yes this should be fixed. I canât count the number of times Iâve written the alias module Body = Cohttp_lwt_body
â 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
|
