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

[João Távora]

Hi Adam,

On Wed, Nov 22, 2023 at 10:41 PM Adam Porter <adam@alphapapa.net> wrote:

> Thanks for this reply of yours from last month.  I hadn't had anything
> to add until now, after we've had more development in our project.

Sorry for the delay from my side.

> Given your experience with these things, does this seem like a
> reasonable solution to you?

I can't see why it wouldn't work, which just means I
can't immediately find a flaw.  I know from experience there
are subtleties very easy to miss in these process filters.

> Or is there still strong reason to prefer
> using a Content-Length header to detect the end of responses?

The drawbacks I see is (1) having to sweep through the data
of every received chunk to look for the newline message
separator and (2) all the escaping and un-escaping work.

Whereas with Content-Length you read a number once, and
continuously subtract from it to know if you have a full
message.  If you do, that's when json-parse-buffer is called,
and that's when you sweep through the data to construct the
JSON object.  It's a more complicated parser but it's already
written and it's proven sturdy.

If I were coding this in C/C++ with performance and memory
concerns it's also probably how I would go about it

Here, I don't know if it makes a difference, you'd have to
measure.

Personally, if the other endpoint was under my control, I'd
just add Content-Length for peace of mind.  Seems easier
than adding escaping anyways.  Not sure if this reason is
strong enough.

João