有各种交换语言 - json，ect--提供快速可靠地导出数据并将数据解析为通用格式的能力。这是语言之间的福音，因为它有Piqi，它基本上为您定义的任何类型生成可解析的交换格式;它自动化编写锅炉代码的过程（编写读取某些交换信息的函数并构建一些任意类型的实例）。基本上，迄今为止最好的选择是协议缓冲区，如果我沿着ocaml-rpc的路线走下去，我绝对想要使用协议缓冲区。
如果有一些声明模式来管理函数暴露会很好，这样可以通过某种媒介（如RPC，或将函数映射到带有参数编码的url）来访问ocaml库。
想象一下提供图书馆作为服务;您不希望或不能在每对语言之间进行实际绑定的地方。但是服务器和数据解析已经编写好了...所以不会有某种方法来集成这两者，只是指定应该公开哪些功能以及在哪里/如何？
最后，在我看来，协议缓冲区是一种机制，您可以通过它快速编码/解码数据，但不是传输机制...是否有某种ocaml-RPC规范或某些ocaml RPC库？ Aren有各种各样的RPC协议（而且，如果我尝试使用diff协议将两种语言相互指向，实现失败）？此外，等待和接收RPC调用的服务器机制（可能）是另一个模块（？）
我如何实现这一目标？
答案 0 :(得分：0)
我认为ocaml-rpc库符合您的要求。它可以推断序列化功能，也可以生成客户端和服务器代码。有趣的是，他们使用OCaml作为IDL语言。例如，这是rpc函数的定义：
external rpc2 : ?opt:string -> variant -> unit = ""
将从中推断出服务器和客户端函数化代码，它们将负责传输编组和解组数据，因此您只需要使用纯OCaml数据类型。
这个库的问题在于它几乎没有记录，因此您可能会发现它很难使用。
此外，正如我现在所知，您正在使用BAP处理，我想提请您注意一个新的BAP 1.x，它将很快就绪，它将具有绑定，允许从任何语言调用它，虽然目前我们主要针对python。
答案 1 :(得分：0)
为了更新这一点，piqi项目下的最新努力旨在产生一个有效的OCaml RPC服务。由此，在视觉上，很容易指定在RPC服务端公开哪些函数，并且客户端上的目标函数选择应允许某些机械化工具允许选择这些公开的函数。
目前，这个用于ocaml的RPC系统有助于数据的语言间交换，解析器可以通过使用原始缓冲区来重建数据。它正在开发中，仍然是being discussed here