Re: jsonrpc.el uses "Content-Length" headers which seem specific to LSP

[João Távora]

On Thu, Oct 19, 2023 at 12:17 AM Adam Porter <adam@alphapapa.net> wrote:

> However, we wonder if jsonrpc.el is not quite as generic as it should
> be, i.e. whether the use of these HTTP-style

Instead of jsonrpc.el, I think you mean jsonrpc-process-connection.  It's
a subclass of jsonrpc-connection.  If you want more genericity, you could
subclass jsonrpc-connection.

To give you an example, in a private project I subclassed
jsonrpc-connection to make a websocket-based JSONRPC transport.
It was really easy (I can show the code if you're interested).

Presumably you're interested in using an Emacs pipe or network process
as the transport, so by doing that you'd find yourself reinventing lots of
stuff in the methods for jsonrpc-process-connection.  Let's label this idea A.

Now, the flaw I will concede about jsonrpc-process-connection is that it
describes itself as a "jsonrpc connection over an Emacs process", but it
would be more accurately described as "JSONRPC connection over HTTP-like
over Emacs process".  Presumably, you want the first and the last part
but not the middle.  I guess we could express the existing
jsonrpc-process-connection as a mixin of HTTP-like behaviour and Emacs
process behaviour.  If we did that, you could more elegantly do your
own hyperdrive-jsonrpc-connection by mixing in just the classes you wanted.
So this is idea B.

Back to idea A, we could just bundle most of the functionality used by
the generics operating on jsonrpc-process-connection as free helper
functions. Then you could just easily build on top of jsonrpc-connection
the process-related stuff you want to do and the existing
jsonrpc-process-connection would also use these helpers.

Nevertheless, I think idea B is cleaner.  From reading your email,
you seem to agree with me.

But I have to see your code first.  You seem to have already come up
with some kind of idea C. You say the code is "pleasantly  simple",
yet you still think it could be easier, so I don't know.  I haven't
seen your pleasantly-simple-but-not-quite-optimal code.

I do know subclassing and removing behaviour violates the "is a"
of inheritance and sometimes brings you into trouble
later on.  Or maybe not.

So, to summarize, changes to the transport implementor's API in
of jsonrpc.el are possible, so long as the current API isn't
broken and the new things, be it helpers of idea A or new classes of
idea B are documented in the manual.  So show me your code and propose
some patch to jsonrpc.el showing how much it would simplify your
existing code.

João