Optionally send `Content-Length` header

[josephmturner]

As I understand it, sending Content-Length headers would make for more efficient parsing of the large JSON payloads in the client, since it can wait to attempt parsing until it has the full object.

[josephmturner]

This would also mean that hyperdrive.el could use some of the higher-level APIs in jsonrpc.el which assume that the server will send Content-Length headers.

[alphapapa]

Here's a spec for JSON-RPC over HTTP, which is not exactly the same thing, but probably what inspired the later spec of LSP, which imitates it: https://www.simple-is-better.org/json-rpc/transport_http.html

[RangerMauve]

Instead of plain JSON-RPC we will use the https://langserver.org/ spec instead.

This will be like HTTP pipelining over tcp but with limited headers

https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#headerPart

[RangerMauve]

Gonna replace the json parser with this: https://npm.io/package/vscode-jsonrpc

[RangerMauve]

Might not use that parser and write my own instead. Too complex and hard to work with.

[alphapapa]

In our group meeting now, we've decided that before we start using Content-Length headers, that we should try using one of the line-based JSON formats, i.e. https://jsonlines.org/ and/or https://ndjson.org/ (not sure if those sites are really just the same thing). Our Elisp code in the process filter would resemble this code in principle: https://github.com/RangerMauve/fetch-event-source/blob/780ac9cf33a3711c7a88e80ddedfe68fc53312aa/fetch-event-source.js#L144-L160

Doing this should theoretically allow us to easily detect when and where a JSON object ends so we can try to parse it, and to do so without having to add support for the Content-Length header to the RPC server.

However, before proceeding with this, Adam will ask Joao if this seems reasonable to him, because he had strongly suggested using the Content-Length header, and he's the author of the jsonrpc library, Eglot, etc.

[RangerMauve]

Instead we'll be using nd-json since it's easier to implement.

[alphapapa]

I replied to him here: https://yhetil.org/emacs-devel/4d3cd934-01a8-41ac-b50b-61ff729c9a2c@alphapapa.net/