From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id 27A2C7FA87 for ; Wed, 18 May 2016 16:27:22 +0200 (CEST) IronPort-PHdr: 9a23:Knvz6hUTs+IWUdu58tRZ9NOp6BPV8LGtZVwlr6E/grcLSJyIuqrYZhKDt8tkgFKBZ4jH8fUM07OQ6PCxHzdYqsnb+Fk5M7VyFDY9wf0MmAIhBMPXQWbaF9XNKxIAIcJZSVV+9Gu6O0UGUOz3ZlnVv2HgpWVKQka3CwN5K6zPF5LIiIzvjqbpq8yVOF0D22D1SIgxBSv1hD2ZjtMRj4pmJ/R54TryiVwMRd5rw3h1L0mYhRf265T41pdi9yNNp6BprJYYAu3SNp41Rr1ADTkgL3t9pIiy7UGCHkOz4S4tW38RlFJtAg7e7wCyCob0sy3htftV2iCcMNbqV705RXKp6KI9GzHyjyJSLT8p/W3/isVolLNfrQq9phc5xJTbM9LdD+Z3Yq6IJYBSfmFGRMsEEnUZWo4= Authentication-Results: mail3-smtp-sop.national.inria.fr; spf=None smtp.pra=rixed@happyleptic.org; spf=None smtp.mailfrom=rixed@happyleptic.org; spf=None smtp.helo=postmaster@pim.happyleptic.org Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of rixed@happyleptic.org) identity=pra; client-ip=5.135.156.187; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="rixed@happyleptic.org"; x-sender="rixed@happyleptic.org"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of rixed@happyleptic.org) identity=mailfrom; client-ip=5.135.156.187; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="rixed@happyleptic.org"; x-sender="rixed@happyleptic.org"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@pim.happyleptic.org) identity=helo; client-ip=5.135.156.187; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="rixed@happyleptic.org"; x-sender="postmaster@pim.happyleptic.org"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BuCQCFezxX/7uchwVegzdVFrppgXUihW8CCIEuOhIBAQEBAQEBAWQngi2CFgEBAwE6PwULCw4TJQ8FSYg6DAEJwyQBAQEBAQEBAwEBAQEBAQEbBYpyhSKCSIIuAQSYK4YAiBaBc4d6hTePSScLMIIGHIFNiHIBAQE X-IPAS-Result: A0BuCQCFezxX/7uchwVegzdVFrppgXUihW8CCIEuOhIBAQEBAQEBAWQngi2CFgEBAwE6PwULCw4TJQ8FSYg6DAEJwyQBAQEBAQEBAwEBAQEBAQEbBYpyhSKCSIIuAQSYK4YAiBaBc4d6hTePSScLMIIGHIFNiHIBAQE X-IronPort-AV: E=Sophos;i="5.26,329,1459807200"; d="scan'208";a="178206045" Received: from pim.happyleptic.org ([5.135.156.187]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 18 May 2016 16:27:02 +0200 Received: from pim.happyleptic.org ([5.135.156.187]) by pim.happyleptic.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1b32RB-0002ra-0W; Wed, 18 May 2016 16:27:01 +0200 Date: Wed, 18 May 2016 16:26:59 +0200 From: rixed@happyleptic.org To: Yaron Minsky Cc: "caml-list@inria.fr" Message-ID: <20160518142659.GB10232@pim.happyleptic.org> References: <20160518134349.GA10232@pim.happyleptic.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Subject: Re: [Caml-list] RPC for OCaml? -[ Wed, May 18, 2016 at 09:52:13AM -0400, Yaron Minsky ]---- > Async-RPC is perhaps worth looking at, though I agree it doesn't give > you much of what you want --- certainly, we don't to RPC over HTTP, we > do it over bog-standard TCP, and the protocol is very much > OCaml-specific, being based on bin-io. Indeed it's interesting. That's only the lowest level part though (the actual communication between two machines). I guess you have some higher layers doing load balancing, service discovery, and so on, but those are private? I'm not actualy looking for RPC over HTTP, I was just mentionning HTTP2 because that's a good middleground between efficient RPC and legacy infrastructures. Indeed, I'd like an RPC library that's oblivious of the transport layer because there can be some mandatory proxy/authentication scheme implemented at this layer already and one may not have other choice than to implement them. > That said, it might be useful > to look at for inspiration, in particular for how versioning is > handled in Versioned_rpc. Versionning is indeed one of the concern I forgot to mention. Although it may be more important to you because of the serialization engine you use. Many serialization formats allow for extensions which in practice aleviate the issue; although it's also a form of manual runtime type checking that can quickly become a source of bug and boilerplate ("moving data from one format to another as a living" kind of feeling). My idea so far was to use whatever is available in the serialization layer for minor additions (as for the transport I'd like the RPC to be adaptable with any serializer, again for interfacing with legacy), and for anything fancier just use plain variant types and let clients and servers deal with them (GADT can be used to make sure we answer a response-v2 to a query-v2, can't they?) or deploy entirely distinct servers and solve this issue at the service-discovery layer. Having an explicit adapter such as versioned_rpc is a good idea. Maybe as part of the adapter to the underlying serializer so that implementers are strongly encouraged to code unserializer in such a way that the service itself deals with only one version. > We do also have some kerberos support in > there as well, though I'm not sure that's in the open source release. https://github.com/janestreet-alpha/krb5 ? Will read all this and maybe come back with more questions if you don't mind.