@volrath did you consider porting nrepl bridge to el?

@cgrand I modularized the two things that are closely related to unrepl: the loop (`unrepl-loop.el`) and the transport format (edn messages parsing in unrepl-ast.el) but I'm pretty sure some of the AST details leaked to some other files. That said, I didn't plan for nrepl per se, but for an encapsulation/modularization of the underlying protocol

The only abstraction you need is the connection (how you get a pair of streams).

@cgrand, sorry, I actually misinterpreted your question. I thought you were asking about supporting nrepl from scratch. To answer your question, no, I haven't thought on porting nrepl-bridge

It shouldn't be too hard though

I remember I read the code a long time ago when you wrote it and I thought it was a viable option

If someone is looking for a short task to help unrepl, porting nrepl-Bridge to cljs (maybe using https://github.com/rksm/node-nrepl-client) would be cool!

@volrath to be clear: we are not talking about supporting nrepl as a whole but using it as a connection method, right?

yes

@cgrand What does the bridge provide exactly? A way to interact with an unrepl using the nREPL communication protocol?

If that’s the case I assume this should work out of the box with CIDER, right?

It’s very hard to figure out what this does from its readme 😄 https://github.com/Unrepl/nrepl-bridge

Not to mention how it is supposed to be used.

@bozhidar sorry this project was quite niche :-)

So unrepl requires a pair of streams connected to a repl. Usually they are provided by a socket to a socket server repl. The bridge (which is part of the client) allows to recreate this pair of streams over a nrepl connection.

@Bozhidar is this description understandable.

> So unrepl requires a pair of streams connected to a repl. Usually they are provided by a socket to a socket server repl. The bridge (which is part of the client) allows to recreate this pair of streams over a nrepl connection.

@cgrand Yeah, I get this. I’m assuming those streams are the equivalent of nREPL sessions.

So, unrepl normally opens two client sockets to socket repl server, right? What are they for - evaluation and control/tooling perhaps?

Actually 3: user input, aux (control/tooling), sideloader (classpath extension).

Also these connections are not created in the same way. The first one (user) is upgraded by sending the blob the other ones are upgraded using expressions provided on the user connection. They are all part of a single user session.

They could be multiplexed over a single link (like nrepl does) but unrepl doesn’t require it. Nothing stops a client from using a multiplexing transport. (See mux as an example.)