Closed gdaniel closed 2 years ago
Hi @gdaniel - I think the issue here is that the json-rpc implementation here was done specifically for LSP (and later adapted for DAP). A fully generic json-rpc implementation was somewhat out of the scope of the LSP4J project despite the comment at the end of that article by @akosyakov.
That said, a clean PR (including tests) that that added such additional functionality would be welcome!
Hi @jonahgraham, thanks for your reply. I understand that a generic JSON-RPC implementation wasn't a priority for the project. Since the project also provides a websocket adapter for JSON-RPC I am now doing some testing with it, and if at some point we come to the conclusion that we need the socket implementation I'll go ahead and work on the PR.
In the meantime I close this issue, thanks again!
I followed this tutorial to create a JSON-RPC client/server communicating through a socket. Then I built a Python client to access the server, but couldn't make it work because my client wasn't sending the
Content-Length
header before the JSON payload, and this header is required by StreamMessageProducer.I guess this issue is very similar to #189, and I understand this header eases the parsing of the bytes stream, but I don't see any header in the JSON-RPC specification. It is part of the LSP specification though, so I am wondering if enforcing this header for every JSON-RPC server is a design decision, or if it crept from LSP to the generic JSON-RPC implementation.