The invocation can be as follows: json-rpc-shell --exec -- gopls serve
Use an AF_UNIXSOCK_STREAM socketpair(2) to communicate with the child. Redirect stderr to a pipe and display data from there in a controlled fashion so that it doesn't disrupt normal operation. Silencing stderr can be done externally by wrapping the command like sh -c "gopls serve 2>/dev/null" if needed, therefore a command line switch for that situation isn't necessary.
Since this feature targets the Language Server Protocol and the standard employs RFC 5322-like "Internet Message Format" headers, this is what we'll do as well. Unlike with WebSockets, there are no natural message boundaries and LSP servers are unlikely to support datagrams. The http-parser library can be re-used for this purpose.
We'll see how much software will work with a Content-Type of application/json; charset=utf-8, as opposed to LSP's application/vscode-jsonrpc; charset=utf-8.
The invocation can be as follows: `json-rpc-shell --exec -- gopls serve`
Use an `AF_UNIX` `SOCK_STREAM` socketpair(2) to communicate with the child. Redirect stderr to a pipe and display data from there in a controlled fashion so that it doesn't disrupt normal operation. Silencing stderr can be done externally by wrapping the command like `sh -c "gopls serve 2>/dev/null"` if needed, therefore a command line switch for that situation isn't necessary.
Since this feature targets the Language Server Protocol and the standard employs RFC 5322-like "Internet Message Format" headers, this is what we'll do as well. Unlike with WebSockets, there are no natural message boundaries and LSP servers are unlikely to support datagrams. The http-parser library can be re-used for this purpose.
We'll see how much software will work with a Content-Type of `application/json; charset=utf-8`, as opposed to LSP's `application/vscode-jsonrpc; charset=utf-8`.
Apparently Content-Type doesn't matter much. We've thrown a full HTTP parser at the protocol, pausing it between requests so that we can inject an HTTP/1.1 POST header line--it turns out the default of Connection: keep-alive is sometimes even convenient. Now blocking solely on adding bi-directionality.
Apparently Content-Type doesn't matter much. We've thrown a full HTTP parser at the protocol, pausing it between requests so that we can inject an HTTP/1.1 POST header line--it turns out the default of `Connection: keep-alive` is sometimes even convenient. Now blocking solely on adding bi-directionality.
p
The invocation can be as follows:
json-rpc-shell --exec -- gopls serveUse an
AF_UNIXSOCK_STREAMsocketpair(2) to communicate with the child. Redirect stderr to a pipe and display data from there in a controlled fashion so that it doesn't disrupt normal operation. Silencing stderr can be done externally by wrapping the command likesh -c "gopls serve 2>/dev/null"if needed, therefore a command line switch for that situation isn't necessary.Since this feature targets the Language Server Protocol and the standard employs RFC 5322-like "Internet Message Format" headers, this is what we'll do as well. Unlike with WebSockets, there are no natural message boundaries and LSP servers are unlikely to support datagrams. The http-parser library can be re-used for this purpose.
We'll see how much software will work with a Content-Type of
application/json; charset=utf-8, as opposed to LSP'sapplication/vscode-jsonrpc; charset=utf-8.Apparently Content-Type doesn't matter much. We've thrown a full HTTP parser at the protocol, pausing it between requests so that we can inject an HTTP/1.1 POST header line--it turns out the default of
Connection: keep-aliveis sometimes even convenient. Now blocking solely on adding bi-directionality.