Sharing client and server on same transport

[ebkalderon]

Does the current design of jsonrpc-core-client allow for a server and client (different schemas) to share the same duplex transport? The use case for this would be a language server, which has a handful of special methods and notifications that are sent from the server to the client, rather than the other way around (see ebkalderon/tower-lsp#13 for further detail). They both also communicate over stdio, which is challenging since one has to be careful to not accidentally feed the responses from the client read on stdin back into the server as though it were a request.

In tower-lsp, I am currently working around this limitation by manually interleaving the responses produced by the server together with extra notifications intended for the client to read all to stdout. This works perfectly for notifications, but I cannot easily support sending requests to the client and picking up the responses, all while sharing the same stdout and stdin used by the server.

As such, it would be nice if there was some way to have the client-to-server schema defined in one jsonrpc-derive::rpc trait, the server-to-client schema defined in another jsonrpc-derive::rpc trait, and to instantiate both using the same stdin and stdout handles.

[ebkalderon]

Come to think of it, this would all be easier if clients would eschew RpcChannel entirely and exposed their functionality via IoHandler or something similar, just like servers currently do. The current design very strongly couples the transport method of streams and sinks to the request and response handling.

Reusing the stdin and stdout handles could be made significantly easier if clients could extend an IoHandler with to_delegate() and client requests could be sent and responded to with IoHandler::handle_request() using whatever streams and sinks one wishes.

[tomusdrw]

To be fair I'd be more inclined to re-design IoHandler and server transports to be more like the client (i.e. first-class async). @tomaka had nice suggestions about the new API and I believe he started some experimentation in https://github.com/tomaka/jsonrpsee

[ebkalderon]

The redesigned API you linked looks quite nice, but it seems to only support HTTP servers at the time of writing. HTTP servers and clients can be very easily made bidirectional due to the nature of the protocol. On the other hand, stdio cannot, since the server and client need to share the same stdin and stdout handles, and they both have to be careful to not accidentally process client responses as server requests or server requests as client responses while reading from stdin.

I imagine that the stdio support added to such a JSON-RPC API would look quite different than what is currently in that repo.

[tomaka]

The redesigned API you linked looks quite nice, but it seems to only support HTTP servers at the time of writing.

Please give me some time to write the code, I started two days ago!

[ebkalderon]

I'm well aware, haha. Don't worry about it! Even in such an early stage, it looks nice and ergonomic so far. I was only trying to raise a point that the IoHandler model seems to work much better with a stdio transport than the RpcChannel model, which the experimental repo currently seems to be taking after.

I hope a satisfactory solution can eventually be found which can handle both HTTP and stdio transports in servers and clients.