Re: [Caml-list] RPC for OCaml?

[rixed@happyleptic.org]

-[ 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.