| There's Language Server Protocol (LSP) which is an open specification from Microsoft, but as far as I can tell it's meant to be a personal server to back a REPL session, not a public server on the internet that serves the same content to everybody in the world.
I looked at their overview here, and I agree with your conclusion:
It sure would be nice to take advantage of all the work they've done, though.
Reuse of what has been done around the LSP can mean these things:
I recently did post here some bits around my Emacs config for some Schemes, and for me the interesting features up to now where:
- Code completion
- Jump to def
- Workspace symbols
- Find references
- Additional capabilities
- There is also already the Debug Server extension for VS Code, but I'm not sure how much traction this got up to now. Given where we start, it will anyway not be on the top of the prio list for the first few iterations ;)
- access to documentation index (per Scheme, RnRS, SRFIs)
- fetching docstring (incl. signature) per symbol, aka hover aka Emacs Eldoc
- code completion per symbol-prefix, e.g. Emacs Company
- jump to def and finding references over all relevant Scheme code would also be interesting; for now I just use here what's available with Emacs out of the box
So for me the LSP already quite well fits the API functionality that we probably would anyway come up with; at least it could be a good starting point to collect such feature set.
Again from the technical point of view, next questions for me would be:
- What is the complete API functionality we want to cover with V1
- Can this API functionality covered with something two-tier: an (Emacs-)client API talking to the HTTP-API-server or
- Do we need something three-tier: an (Emacs-)client API talking to a local REPL which again talks to the HTTP-API-server and can also provide some more details by running a local session. These "details" could be very helpful things, but then we're also already talking about not only about the API-server but n API-REPL clients.