Modified to allow for hooks into the code

[dpp]

trafficstars

This pull request updates a lot of Gorilla REPL to allow for an external system to hook into Gorilla REPL.

There are options for overriding fixed strings in the client by sending configuration information (e.g., Title).

The worksheet.html file can live at a different context path and all the services are relative to this context path (e.g., /worksheet.html becomes /foo/bar/worksheet.html)

Resources (e.g., webservices URLs, MathJax, etc.) are accessed securely if the original page was served via HTTPS.

There's a 1 second ping between the client and server (over the websocket) to keep the web socket alive across proxies.

[ghost]

Hey, Interesting patch, could you explain the use case for each feature a bit?

By overriding fixed strings, do you mean overriding the welcome message?

Is the context path the clojure namespace path of the file? If not, wat would it be used for? Multiuser systems with different services for each user?

Why piggyback data send by the server onto the ping? Doesn't this create a potential latency of one second for mushed info? Why not have a separate message type?

Happy holidays, Cheers Jan

[dpp]

Overriding the welcome message and some of the other text allows customization of the UI experience.

When I used Gorilla as part of https://vimeo.com/109288432 I needed to change up some strings and served it via https to a session-unique URL... e.g. https://telegr.am/visi/xxxyyyzzz/worksheet.html

Serving to that URL (using HAProxy to send the HTTP traffic to the correct URL) means changing up the path in both the browser and the server.

I looked for a way to send messages from the server to the client, but there's no place I could find to store the websocket on the server (and associate it with the session), so I opted for a ping/poll model.

[JonyEpsilon]

Thanks David. I'll take a look at this shortly when I have a chance :-)

[JonyEpsilon]

Hi David,

sorry for the slow reply. I’ve had a chance to think about the changes in this PR, and it also prompted some more general thinking about what should be in the core of Gorilla, and what is more appropriate in a fork. And I don’t think very quickly!

Let me try and comment separately on each part of the PR:

• welcome message, initial segment content. As well as customisation, there would be some value in moving the strings in the app into one place for i18n purposes. My feeling, though, would be to hold off on doing i18n until there’s demand, but I appreciate that that might be native-English-speaker’s privilege talking! As far as customisation goes, see the next point …
• webapp paths, worksheet name, worksheet title, save message suppression, save hook. When thinking about the scope of Gorilla, I think I’d prefer to keep it limited to being Gorilla-the-app, rather than Gorilla-the-library for writing notebook front ends. Which is not to say that Gorilla-the-library wouldn’t be a good thing, just that I don’t think I want to maintain it! So, I’d say, in that context, that these changes (and the ones above, unless we fully pull out the strings) are more appropriate living in the fork.
• touching file on startup. There’s already a .gorilla-port file written out when Gorilla starts. Does this additional file do anything that couldn’t be done with the .gorilla-port file?
• save on evaluate. This is a feature that has been requested quite a bit, see #48. It would be ideal if this could be user configurable through Leiningen. I’d like to see this in Gorilla.
• ping. My current thinking is to keep “interactive” output out of core Gorilla. This is because I haven’t seen any way of doing it that is general and keeps the core simple and predictable, which I think is an important property. So, I don’t think I see a place for ping in the core, as it mainly exists to provide a route for the server to move unsolicited output back to the client. There is work that could be done to improve the web socket connection handling, but I don’t think ping is the right way to go.
• tex and fonts over appropriate protocol. No-brainer, this should be merged in.

I hope that doesn’t come across as too negative. I really appreciate you sending the changes through, and it has prompted some useful and serious thinking about the direction I want Gorilla to go in. Or, perhaps more truthfully, the direction I have the resources to keep it going in! And I am open to disagreement and argument on anything I’ve said :-)

In terms of action: I can pick out the bits of the PR that I’d like to merge in, if you’re happy with that. Or I’m happy if you want to change the PR. And of course, I’m happy for the discussion to continue before doing anything to the code :-)

Jony

[dpp]

Jony,

After reading your feedback, I realize that what I'm doing is not well aligned with where you are taking Gorilla REPL. I am a firm believer in respecting the project founder because the founder's vision is important in making a project something useful for all.

I think the best bet is the fork option for me. Please take whatever bits and pieces you want from this PR (or ignore it altogether).

I will continue to maintain a fork of Gorilla REPL that has the pieces I need... more of the Gorilla as library rather than Gorilla as app. If there's anything that's app-general (e.g., a better keep alive mechanism for the web socket), I'll ping you and see if you want it.

Thanks for building something great and thanks for your thoughtful comments!

Rock on!

David

PS -- I'll leave it to you to close the PR or continue the conversation... either is cool with me.

[JonyEpsilon]

Hi David,

thanks for the considered reply. I'm still trying to feel out the scope of Gorilla - my main fear is expanding beyond my or others' ability to continue maintaining the project, as I wouldn't like to see it turn into abandonware.

The plan of working on a fork sounds like a good one, and I'll try and keep an eye on it - and also keep you up to speed as the plan for Gorilla evolves.

I'll leave the PR open and pull out the bits that are going to go in when I have a chance.

Thanks again,

Jony