Embedded Gorilla

[strongh]

@yieldbot we'd like to host our own Gorilla webserver to use within the company. Sort of our own internal/private viewer.

I don't think that it should be too difficult to support Gorilla as a library... but there are a few pieces to figure out:

• packaging static resources
• starting nREPL server
• adding necessary routes (possible with configurable prefix?)
• where to save/load notebooks

I think that's all manageable. This is something for which we might contribute a PR if there's interest. Is there any interest, and is there existing work that might be reused (e.g. for the online viewer)?

[JonyEpsilon]

The online viewer is currently serves the files out of the gorilla-repl jar. It has a dependency on gorilla-repl (from clojars) which has the static resources included in the jar under the resources/public directory.

The viewer doesn't need an nREPL server, and if you wanted to run your own viewer all you would need to do is to serve the files in the gorilla-repl jar, plus connect up some way to load notebook data from wherever you'd want to store them.

If you want to run your own gorilla server that can be used to execute code, then it would be a little bit different. Essentially you'd just want to run gorilla as you do at the minute, but on the server. It already supports multiple simultaneous sessions. There are a few things in pipeline to make it easier for multiple users to work on the same server, thanks to @gfredericks and colleagues: worksheet filenames in URLs and default separate namespaces for each worksheet.

If you're thinking about embedding Gorilla in an existing server process, then the easiest thing to do would probably be to host an nREPL server in the server process, and connect to it from a locally hosted gorilla client. This would require adding an option to allow selecting the nREPL server to connect to (currently always defaults to local).

I'm certainly open to patches that improve server deployments, so long as they don't compromise the single-user experience. Perhaps you could outline what particular usage you'd like to see possible?

[strongh]

We want to execute code, and we'd like to embed Gorilla in an existing (ring/compojure) server process. Starting an nREPL server makes sense, but I'm unsure what you mean by "locally hosted"... local to the webserver? Or local to HTTP clients (e.g. browsers). If the nREPL server is on the JVM as the the HTTP server, then they also share a host and so the nREPL client would still be "local". Please let me know if that isn't right, maybe I missed something or don't understand you properly.

Thanks for your input! I'll begin looking more closely at Gorilla's internals.

[JonyEpsilon]

I'm not sure I explained it very well, let me try again!

There are really three parts to a running Gorilla session: a standard nREPL server, the Gorilla server, and the client-side code. If you run Gorilla from leiningen on your machine then:

• the nREPL server runs locally (i.e. on that machine) talking over a socket
• the Gorilla server runs locally, talks on a socket to the nREPL server, and serves http/websocket to the client. The gorilla server loads and saves worksheet files.
• the client runs in the user's web-browser, talking only to the Gorilla server.

The actual execution of clojure code happens in the nREPL server, so if you just want to execute code on a remote machine, then the only bit that needs to run remotely is the nREPL server. And there's a standard (and easy) way to embed an nREPL server in an existing clojure process.

So, one way it could work is: have nREPL server running on remote machine, user runs gorilla server on local machine connecting to remote nREPL. This would give you remote execution, but worksheet files would still reside on the user's machine.

Or: you could run both the nREPL server and the Gorilla server on the remote machine, and then the user just points a web-browser to the remote Gorilla server. The worksheet files would then live on the remote machine.

The second option would just work as is. The first option would require a few minor changes to allow a remote nREPL server to be specified as an option.

Hope that makes more sense.

[strongh]

Thanks for the in-depth explanation. This makes sense, and clarifies my previous confusion. I had not considered the first option.

I'm interested in your second option :), it is the one that I have had in mind. I intend to embed both the nREPL server as well as the Gorilla server in an existing process. And I would like for worksheet files to live on the remote machine.

[JonyEpsilon]

Going to close this one. Have opened an issue that addresses the changes that would be needed to support "option 1" (remote nREPL) #137.