From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id 362F97F0BB for ; Mon, 29 Aug 2016 20:42:14 +0200 (CEST) IronPort-PHdr: 9a23:WW/ZnxZe2uUa6K2FHTNAHlD/LSx+4OfEezUN459isYplN5qZpc6+bnLW6fgltlLVR4KTs6sC0LuP9fy8EjVYu97B6ClEK8McEUddyI0/pE8JPo2sMQXDNvnkbig3ToxpdWRO2DWFC3VTA9v0fFbIo3e/vnY4ExT7MhdpdKyuQtaBx+z+7e25+oXSbgNUn3L9JOoqdFTl5TnW4/MLjYoqBbwwzBHEuHQAL/5LyWIuKkiSmRzx/MiY85tq8iAWsPUkoZ1uS6L/KogxV71fRAgrMnA45dfi/U3PRBGO4T0AX2QGnxtSCiDD6BzrQpr39CD9s7wui2GhIcTqQOVsCnyZ5KBxRUqt0X9fOg== Authentication-Results: mail2-smtp-roc.national.inria.fr; spf=None smtp.pra=dario.teixeira@nleyten.com; spf=None smtp.mailfrom=dario.teixeira@nleyten.com; spf=None smtp.helo=postmaster@relay3-d.mail.gandi.net Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of dario.teixeira@nleyten.com) identity=pra; client-ip=217.70.183.195; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="dario.teixeira@nleyten.com"; x-sender="dario.teixeira@nleyten.com"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of dario.teixeira@nleyten.com) identity=mailfrom; client-ip=217.70.183.195; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="dario.teixeira@nleyten.com"; x-sender="dario.teixeira@nleyten.com"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@relay3-d.mail.gandi.net) identity=helo; client-ip=217.70.183.195; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="dario.teixeira@nleyten.com"; x-sender="postmaster@relay3-d.mail.gandi.net"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CPAgCrgcRXh8O3RtlcGwEBAQMBAQEWAQEBAwEBAYMKAQEBAQF1gQO4JoIBglaDRwKBVzoSAQEBAQEBAQEBAQESAQEBCA0JCRkvgjIEARUBBIIRAQEDATgCPwULBAdGVwYbE4gdDL4NAQEIAgEkhi6ETYQqhXIFmU+BZI1Aj1yQOwIlCIJsgViFe0F/AQEB X-IPAS-Result: A0CPAgCrgcRXh8O3RtlcGwEBAQMBAQEWAQEBAwEBAYMKAQEBAQF1gQO4JoIBglaDRwKBVzoSAQEBAQEBAQEBAQESAQEBCA0JCRkvgjIEARUBBIIRAQEDATgCPwULBAdGVwYbE4gdDL4NAQEIAgEkhi6ETYQqhXIFmU+BZI1Aj1yQOwIlCIJsgViFe0F/AQEB X-IronPort-AV: E=Sophos;i="5.30,597,1470693600"; d="scan'208";a="234443514" Received: from relay3-d.mail.gandi.net ([217.70.183.195]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Aug 2016 20:42:13 +0200 Received: from mfilter18-d.gandi.net (mfilter18-d.gandi.net [217.70.178.146]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id 8A211A80D2; Mon, 29 Aug 2016 20:42:13 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter18-d.gandi.net Received: from relay3-d.mail.gandi.net ([IPv6:::ffff:217.70.183.195]) by mfilter18-d.gandi.net (mfilter18-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id TFg0H_k1_1nJ; Mon, 29 Aug 2016 20:42:10 +0200 (CEST) X-Originating-IP: 10.58.1.141 Received: from webmail.gandi.net (webmail1-d.mgt.gandi.net [10.58.1.141]) (Authenticated sender: dario.teixeira@nleyten.com) by relay3-d.mail.gandi.net (Postfix) with ESMTPA id 54A65A80CB; Mon, 29 Aug 2016 20:42:10 +0200 (CEST) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 29 Aug 2016 19:42:10 +0100 From: Dario Teixeira To: Rudi Grinberg Cc: caml-list In-Reply-To: <20160829153945.424bhlwpk7pmm6em@rgcaml.localdomain> References: <20160829153945.424bhlwpk7pmm6em@rgcaml.localdomain> Message-ID: X-Sender: dario.teixeira@nleyten.com User-Agent: Roundcube Webmail/1.1.2 Subject: Re: [Caml-list] Functorising over Cohttp's backends Hi, And thanks for the comprehensive response, Rudi! > The Cohttp API at its present state doesn't really offer a good > abstraction for creating backend independent HTTP clients and > servers. > > Luckily, the request and response types are backend independent. And > so is the http body type if you aren't streaming. This means that > you can fairly easily create a light application specific abstraction > for yourself. Yes, I'm leaning towards just functorising over "IO" and nothing else. I thought about functorising also over "Body", but I reckon the API will be much simpler if I dictate that the body must be of type Cohttp.S.Body.t, and place on the user the burden of converting to/from this type if the backend body implementation extends over Cohttp.S.Body (as is the case with Cohttp_lwt_body). I reckon a truly universal solution would also need to functorise over "Request" and "Response", but a) that way lies madness, and b) as you pointed out, luckily these are presently backend-independent. > To summarize, it's unfortunate that Cohttp doesn't provide a real > server (or client) abstraction. But it's kind of hard to do without > making a wrapper that tries to abstract away the differences between > different backends. Hiding away the details of Async and Lwt was > always an anti-goal for Cohttp anyway. Cohttp is perhaps the poster child for how the Lwt/Async schism makes many APIs way more complex than they should be! (Not that there's an easy solution to this situation...) Best regards, Dario Teixeira