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.
The reason for this is that RPCs often do something like look something up in a master structure. This way, Implementation.ts can be created without having the master structure in your hands.
val sexp_of_t :
('connection_state -> Sexplib0.Sexp.t) ->
'connection_state t ->
Sexplib0.Sexp.tval description : _ t -> Description.tval shapes : _ t -> Rpc_shapes.tWe may want to use an 'a t implementation (perhaps provided by someone else) in a 'b t context. We can do this as long as we can map our state into the state expected by the original implementer.
Note f is called on every RPC rather than once on the initial connection state.
val lift_deferred : 'a t -> f:('b -> 'a Async_kernel.Deferred.t) -> 'b tSimilar to lift, but useful if you want to do asynchronous work to map connection state. Like lift, f will be called on every RPC. This can make RPC implementations less efficient if they were previously relying on functions like Rpc.implement' to avoid extra async work to send responses. This can also allow blocking implementations to run in a different order from the order that queries arrive on a connection.
Additionally, async exceptions raised by One_way RPCs do not currently respect on_exception and will unconditionally close the connection. lift_deferred can turn synchronous exceptions in One_way implementations into asynchronous ones, triggering this behaviour.
val with_authorization : 'a t -> f:('b -> 'a Or_not_authorized.t) -> 'b tval update_on_exception : 'a t -> f:(On_exception.t -> On_exception.t) -> 'a t