search

JonyEpsilon / gorilla-repl

A rich REPL for Clojure in the notebook style.
http://gorilla-repl.org
MIT License
887 stars 104 forks source link

automatically open the worksheet URL in the browser #211

Closed dtolpin closed 7 years ago

dtolpin commented 9 years ago

Many notebooks automatically open the notebook URL in the browser upon launch. This functionality is easy to implement in Java. If desired, it can be made optional, with either default, but I thought that the fewer options the better.

casidiablo commented 9 years ago

I like this. It might be worth trying to catch UnsupportedOperationException just in case.

JonyEpsilon commented 9 years ago

I've argued against this feature a number of times, for several reasons (see #46 and #180). I'm still not that keen on it, but will perhaps have to cave in to public pressure as it's clearly something that people want!

Part of me still doesn't think it's in the right place, though, as the gorilla server is often run server side, where opening a browser doesn't make any sense. @j-pb suggested incorporating it instead into lein-gorilla. I'm not sure about that either, for the same reason. It feels to me like the real solution is to have some other thing which makes using Gorilla on the desktop more user friendly. I talked about this a bit on #184, and have experimented a bit with a few of the ideas in there, but am not really happy with any of them. I guess my overall feeling is that adding browser-auto-open is a solution to a problem that does exist, but is not the right solution in the right place. Ideas very welcome, and I'm also not absolutely against having it in core Gorilla if that works out to be a reasonable compromise. But I would like to think a bit more about whether there's a better way.

kurtharriger commented 9 years ago

I agree that this isn't quite the right place for this code. I have run gorilla server from a docker container with some things preinstalled and configured.

However, I don't see any issue with the feature provided a command line option to enable or disable the feature. Since this is probably the most common use case open by default with an option such as --no-open-browser would still allow for headless deployment if desired.

dtolpin commented 9 years ago

Hi,

thanks for the feedback. I do not mean to insist on usefulness of the patch, I just want to provide more information.

One hand, the patch handles just find headless execution. awt throws headless exception if there is no head.

On the other hand, I think that the hesitation is at least partly because of a more general design problem. In my opinion HTTP client/server should not ever be allowed (or at least shouldn't be encouraged) to be a remote protocol for gorilla repl. The way the server is implemented (and it is entirely appropriate to implement it this way), it is essentially single-user.

Instead of allowing to connect remotely via HTTP, gorilla-repl should be able to connect to a remote NREPL. That's much better from many points. I actually was going to submit a patch for that.

JonyEpsilon commented 9 years ago

Hi David,

always very happy to see patches and opinions :-)

That's an interesting point you make about using Gorilla remotely over HTTP. I'm not sure that nREPL solves it though. I think the fundamental problem is that there's no such thing (that I'm aware of) of per-user port-level security. So if a user exposes an nREPL server on a port, then any other user of that machine can execute commands as the nREPL user. I think, in this regard, that it's pretty much equivalent to a user running a Gorilla process on the server.

That said, it would be extremely useful to be able to connect to remote nREPLs, so if you do have code for that then a patch would be great!

Jony