@cgrand I meant that pure streaming REPLs are composable, but limited.
@cfleming it’s with the composability that I strongly disagree. When repls are nested their powers don’t compose because only the innermost is running.
@cfleming imagine you have two repls: one which uses pprint and the other with a slightly more informative prompt. There’s no way to get both features at the same time.
@cgrand Yes, I agree - compose is the wrong word. I’m really talking about them being nestable.
Sideloading (loading resources/classes from the client without shared filesystem) in nrepl works: https://github.com/nrepl/nrepl/blob/0cfa805ce7f249c5fd9da4bb5343f3130bbc5784/test/clojure/nrepl/core_test.clj#L608-L613
This implementation doesn't allow for transports to be sideloaded. Unless we add support for nesting perhaps.
Why would you want to change transport?
Switch encoding over same connection or install a new connection?
@dominicm could you describe the scenario you have in mind?
@cgrand now you have made the logistics clear, I think same connection is better for firewall reasons. My reasoning is that editors currently have to specify the transport the user chooses ahead of time in the server, eg vim might choose a json transport, but Emacs uses edn. Perhaps it would be useful for clients to bring a transport, and upgrade a standard connection somehow.
What are the connection means in use today? TCP socket, stdin/stdout and drawbridge?
An injectable nREPL over plain repl would cover the first two cases. Then maybe we would need a drawbridge-lite
In practice? Bencode only,
Pretty much anyway afaik.
Yes, bencode, but I'd like to switch over to EDN for Calva. I guess most Calva users are in control over the server.
No drawbridge in practice?
I hear someone trying it occasionally, but not really
Does anybody know of a middleware which uses raw binary (byte arrays)? It seems unlikely given my understanding of the whole stack but I prefer to ask.