Re: [Caml-list] RPC for OCaml?

[Yaron Minsky <yminsky@janestreet.com>]

Yeah, we have some service-discovery stuff and the like that's
internal, and probably not useful outside of our context.  Async RPC
is relatively independent of the transport; Async_rpc_kernel lets you
sub in any transport you want, and we've used that flexibility to use
it over websockets.

y

On Wed, May 18, 2016 at 10:26 AM,  <rixed@happyleptic.org> wrote:
> -[ 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.