[Gluster-devel] XDR RPC Spec

[Jeff Darcy]

> As a community
> if we would like to increase adoption of Gluster I think it would be
> good if other languages could produce bindings in their native language
> without needing to use the C libraries.  If I'm writing code in Java or
> Rust or (name your language here) and I see a Gluster library that is
> pure I'll take that over a library that is just C bindings.

The question is: bindings to what?  At what semantic level?  It would
certainly be possible to change the XDR definitions, but it's not clear
how much value we'd really gain.  For one thing, as I've mentioned
recently in the xdata thread, XDR is a poor choice for us anyway.  I'd
really prefer to replace it for our internal use, though of course it
would still be in play out in Ganesha-land.

More importantly, even a perfect wire-format definition would be of
little value to most people.  Our use of these low-level primitives is
invariably governed by protocols, from the initial connection handshake
to the complex dances done by translators like DHT and AFR.  Raw RPC
calls not in conformance with those protocols will often result in
errors, including operations being prohibited because to do otherwise
could result in data (or metadata) corruption.  The bindings that
matter, that will actually enable developers to do something other than
drive us and them insane, are the ones that either inject higher-level
operations ("fops") into the translator stack or intercept them once
there.  Those bindings do exist, for Python and to some extent for Go.
Any other language with a decent foreign-function interface should be
able to wrap the C calls as those do.  It's about a hundred times easier
to add interesting new functionality that way than by trying to
reverse-engineer what we've done at the RPC level.

Perhaps it would be useful for you to give a bit more detail on what
you'd like to use these Rust bindings *for*.  Then we can probably have
a good discussion on what the best approaches are, instead of jumping
into what's probably the most painful choice.