|
From: | Adam Porter |
Subject: | jsonrpc.el uses "Content-Length" headers which seem specific to LSP |
Date: | Wed, 18 Oct 2023 18:17:35 -0500 |
User-agent: | Mozilla Thunderbird |
Hi João, et al,In our work on hyperdrive.el (a new project currently packaged on NonGNU ELPA), we're beginning a refactor to use a JSON-RPC backend rather than the HTTP-based API we've been using. In the process we've discovered that jsonrpc.el seems to hard-code the use of HTTP-style "Content-Length" headers. These are required by LSP (obviously, one of the major use-cases for jsonrpc.el), however, as best we can tell, JSON-RPC itself does not mention the use of these headers.[0] And, in fact, the RPC server we're connecting to does not expect them nor send them, and it fails when encountering them.
With jsonrpc.el being based on EIEIO and generic methods, we work around this easily enough by defining our own process connection type subclassing jsonrpc-process-connection with associated methods that omit the header-related code (not sending the header with requests, and not looking for one when parsing responses, just trying to parse the incoming text as JSON). This seems to work well, and the code is pleasantly simple.
However, we wonder if jsonrpc.el is not quite as generic as it should be, i.e. whether the use of these HTTP-style headers should be done in a specific subclass rather than the jsonrpc-process-connection one, so that other, non-LSP JSON-RPC servers could be used more easily. Would that be reasonable, or am I missing something (which wouldn't be surprising, as some of this is new territory for me)?
I hope I'm not retreading old ground by bringing this up; I searched the list and bug tracker but couldn't find anything relevant.
Thanks, Adam 0: https://www.jsonrpc.org/specification
[Prev in Thread] | Current Thread | [Next in Thread] |