Legend:
Library
Module
Module type
Parameter
Class
Class type
A library for building asynchronous RPC-style protocols.
The approach here is to have a separate representation of the server-side implementation of an RPC (An Implementation.t) and the interface that it exports (either an Rpc.t, a State_rpc.t or a Pipe_rpc.t, but we'll refer to them generically as RPC interfaces). A server builds the Implementation.t out of an RPC interface and a function for implementing the RPC, while the client dispatches a request using the same RPC interface.
The Implementation.t hides the type of the query and the response, whereas the Rpc.t is polymorphic in the query and response type. This allows you to build a Implementations.t out of a list of Implementation.ts.
Each RPC also comes with a version number. This is meant to allow support of multiple different versions of what is essentially the same RPC. You can think of it as an extension to the name of the RPC, and in fact, each RPC is uniquely identified by its (name, version) pair. RPCs with the same name but different versions should implement similar functionality.
When your implementation raises an exception, that exception might happen before a value is returned or after a value is returned. The latter kind of exception is what the ~rest flag to Monitor.try_with is dealing with.
A 'connection_state Implementation.t is something that knows how to respond to one query, given a 'connection_state. That is, you can create a 'connection_state
Implementation.t by providing a function which takes a query *and* a 'connection_state and provides a response.
A 'connection_state Implementations.t is something that knows how to respond to many different queries. It is conceptually a package of 'connection_state
Implementation.ts.
The output type of the f passed to dispatch_iter. This is analogous to a simple unit Deferred.t, with Continue being like Deferred.unit, but it is made explicit when no waiting should occur.
A state rpc is an easy way for two processes to synchronize a data structure by sending updates over the wire. It's basically a pipe rpc that sends/receives an initial state of the data structure, and then updates, and applies the updates under the covers.
An RPC that has no response. Error handling is trickier here than it is for RPCs with responses, as there is no reasonable place to put an error if something goes wrong. Because of this, in the event of an error such as dispatching to an unimplemented RPC, the connection will be shut down. Similarly, if the implementation raises an exception, the connection will be shut down.