Clojurians Log v2
nrepl
I’m considering trying to connect to nREPL from a web app / chrome extension for a project. is there any prior art for something like this?
Drawbridge I think
I’m looking at drawbridge, which seems like it might be the way to go.
yeah
I’m a bit bummed that it requires a separate dep. the dream would be that I could just connect to any old nREPL server
Think the fundamental limit is that a web app will need to speak http or ws
and I don't think Java standard libraries provide either of those.
yeah. I wish there was some way for Chrome to connect to a regular ol’ socket 😭 pulling in an HTTP server for every project using nREPL seems potentially problematic
> I’m a bit bummed that it requires a separate dep. the dream would be that I could just connect to any old nREPL server (edited)
That’s hard to do as you need to bundle somehow an HTTP server with the REPL. Leiningen used to ship Drawbridge at some point, but I’m not sure if that’s still the case.
In theory we could have a trivial self-contained http implementation bundled with nREPL, but there never was a lot of demand for this.
makes sense.
would you take a PR with something like that? I might be able to put something together, but I also understand if it’s just increasing surface area to support for something not many other people need
what's the usecase here, @lilactown?
I’m working on some devtooling a la REBL for the browser
I previously implemented my own shoddy protocol on top of websockets for Node.js / JVM, but I was thinking i might be able to simplify my life by just connecting directly to a REPL
I think the side loading work might be useful here?
I guess not actually, as you can't sideload a transport
specifically I’m now pivoting to a chrome extension that would connect to a remote session: CLJS in an inspected page, Node.js, and JVM. I previously implemented different “adapters” for each platform, but I know that most projects already have nREPL which would reduce dependencies users would have to install and potentially reduce the differences in implementation
this might be useful?
I looked at that as well. it’s still another transport, right? and it didn’t look like it had been updated in awhile, so I wasn’t sure if it supported the latest nREPL
I imagine step one is getting this all to work with drawbridge/your own http transport
and then check if it's worth trying to merge the functionality into nREPL
I've seen some roll-your-own HTTP implementations, and if you are super narrow about the usecase, it can be manageable. But all depends on what it looks like
yeah. I’m afraid that it will bloom into “now nREPL has a fully-fledged HTTP server impl” lol
> I looked at that as well. it’s still another transport, right? and it didn’t look like it had been updated in awhile, so I wasn’t sure if it supported the latest nREPL
Not really. It’s just a ClojureScript REPL based on piggieback.
> yeah. I’m afraid that it will bloom into “now nREPL has a fully-fledged HTTP server impl” lol
That’s always a possible outcome. 😄
> I guess not actually, as you can’t sideload a transport
@dominicm You won’t need to sideload it, thouhg. You could inject it in the initial payload you’d use to convert a socket repl to nREPL. Once we get there that is. @cgrand already has some branch where the injection works, so I guess that’d be just an extension of this idea.
isn't it a way to speak to piggieback via a websocket?
think it's part of boot's counterpart to lein-figwheel
hmm no the injection is not done yet (been busy)
yeah, I know. Just remember that demo you showed me way back in December and that we spoke that the injection could be a good way to provide custom transports seamlessly.
@bozhidar I don't think that browsers let you make arbitrary socket calls.
Good point. That approach would work for conventional clients, but not for @lilactown’s use case.
I kind of want just a dumb endpoint that I could dump some code into to “inject” stuff, like a heavier HTTP transport if needed
An interesting idea would be to have the default transport allow sideloading via a very dumb detection of http request
Not sure how much parsing would be needed for the cases we want to support.