Server Sent Events support

[jpmonettas]

For IDEs/editors to be able to display whatever is written into *out* server side (ideally) there needs to be a way for the server to send messages to the clients which are unrelated to a specific input request message.

Currently for this cider-nrepl provides things like out-subscribe op in the out middleware. This works for Cider because the elisp nrepl client listens to any response packet with a :out key and adds it to the buffer, so Cider can "render printlns" not related to any message it sent.

Now if you want to support this from a client using the official nrepl client you can't easily, because it only provides a way of reading responses for the messages you sent in a sync way.

So the question here are :

• is nrepl lacking client support for this ?
• is cider-nrepl "abusing" the protocol in a hacky way?
• should nrepl support SSE?
• or am I missing something?

[bbatsov]

is cider-nrepl "abusing" the protocol in a hacky way?

Perhaps. I had added the special handling of out messages in CIDER very long ago - before out-subscribe existed and before I became the maintainer of nREPL. Basically back then some out messages (e.g. from background threads) were coming without request ids and CIDER didn't know what to do with them, so I needed to hack around this. out-subscribe was an attempt for a more civilized solution to the problem. Ultimately, it'd be great to tackle this somehow in nREPL itself, as it'd render the existing hacks and workaround redundant.

See clojure-emacs/cider#853 (clojure-emacs/cider#853 (comment) in particular)

should nrepl support SSE?

Depends on the use-cases we can think of. cider-nrepl can push "notification" messages, which are one such use-case. I haven't thought of anything else that might be useful, so suggestions are welcome.

[cichli]

is nrepl lacking client support for this ?

Yes. Relevant code is here. The existing sync client transparently wrapstransport/send and then returns a lazy seq of the responses which spins calling transport/recv until we receive a response with status of done.

is cider-nrepl "abusing" the protocol in a hacky way?

Even nrepl itself will respond with messages subsequent to sending the done status – if an evaluated form writes to either *out* or *err* after evaluation completes (e.g. (future (Thread/sleep 1000) (println "foo"))). In the context of an eval, the responses containing any asynchronous output contain the originating request's id and session.

The out-subscribe middleware in cider-nrepl is for capturing anything written to *out*/*err* as they were bound at the time the middleware namespace was loaded (usually library code that uses print/println for some reason), and System/out/System/err. In this case the responses contain the session of the originating subscribe request.

should nrepl support SSE?

I think the problem is the interface of the client. Using seqs as queues like this is so brittle – it's very easy for callers to accidentally cause deadlocks, and if a bug means the done message is never returned then the client deadlocks. We should offer an async client that e.g. accepts an on-receive callback.