nREPL middlewares abuse :value in responses

[cemerick]

I was poking around the nREPL middleware a bit, and noticed that many (all?) of them use :value in their responses to convey data/content that is generally not clojure.core/readable…which is generally the intent of :value (thus the utility of things like e.g. read-response-values). I realize now that that isn't documented anywhere explicitly (not in the nREPL README or in the ops.md document), something I'll be correcting shortly.

The practical effect of this right now is probably ~nil, given the probably-tight binding that currently exists between ritz and the tools that support it (i.e. the latter can just make sure not to adjust their handling of :value slots in responses to ritz-specific message IDs). But I think ops like this will end up being a lot more useful (and require much less coordination viz. nrepl-discovery if their responses are as self-describing as possible, up to the point of there being a set of common response "schemas" that clients/tools can react to generically (rather than operationally tracking message IDs and such to strictly control how to respond to response data).

Thoughts?

[hugoduncan]

Chas Emerick notifications@github.com writes:

I was poking around the nREPL middleware a bit, and noticed that many
(all?) of them use :value in their responses to convey data/content
that is generally not clojure.core/readable…which is generally the
intent of :value

OK, that intent hadn't been understood, but it definitely makes sense to
have a common interpretation of message keys if possible. The ritz
middleware should probably either make its responses readable, or use a
different key.

Many of the ritz responses are intended for consumption by the
environment hosting the nrepl session, and are probably in a format that
is readable by elisp (mainly due to emacs being the sole ritz client to
date). One of the aims of NREPL was to make REPL sessions easy to
control from outside of a clojure environment - is there now any
recommendation for the format of responses intended for the REPL host
environment (e.g., emacs, CCW, etc)?

[cemerick]

Recommendation, no. But, see @technomancy's nrepl-discover and the proposal therein; I have some misgivings of its contents, but that's probably the weightiest consideration of the problem to date. Its README links to a clojure-tools thread where some discussion has been had as well.

In hindsight, my inclusion / support of synthetic message identifiers by default in nREPL was likely a mistake, insofar as it encourages unnecessary coupling between sends and receives. A lot of people have taken to using nREPL sessions solely as dumb asynchronous eval channels, which is unfortunate from a tooling interoperability standpoint (not everyone has pr or read in their tool runtimes, nevermind a local eval to obtain results). I'd like to see tooling middleware that starts from a definition of request and response message structures, and proceeds from there. Then, tools should only have to concern themselves with dropping requests with a particular shape into the head of a transport, and blindly dispatch responses off to whatever the local rendering facilities are.

FWIW, part of my sniffing around ritz was in conjunction with work on my vim-fireplace fork, which I'd like to enrich with much of the functionality that ritz provides. Presumably, whatever we can work out between the demands of emacs, vim, and CCW use cases should be a reasonable first approximation of a lasting solution.