Comment by 🦎 bluesman

@clarahd Nothing about it violates the spec so there's no way for it to become "defacto added spec". It's a service - like Fumble Around or NewsWaffle. It places zero burden on Gemini users or authors of Gemini clients.

It's basically CGI for people without access to CGI.

Jul 10 · 6 months ago

7 Later Comments ↓

Do you plan to release the source code for Scriptonite? It could be very useful as a self-contained, Gemini-oriented CGI framework.

I imagine a scenario where Scriptonite is the only executable file inside a capsule's 'cgi-bin' directory, so all maintenance, development and security can be focused there. It has a configuration file with a whitelist/blacklist for which URLs can be loaded. A capsule operator can then restrict the service only to URLs on his own capsule, or he could act as a public Scriptonite host for others.

This could work especially well if Scriptonite had an option to print everything on the Gemtext page as-is that isn't inside a code block. Capsuleers could write all the static content of a page in Gemtext directly, while Scriptonite is only used to execute the dynamic parts. That would greatly simplify writing CGI scripts for Gemini.

@bluesman @clarahd That and, imo, nobody should place the burden of ruining the Gemini ecosystem, or violating the spec, on someone who decided to make a server-side scripting engine, when the burden should be placed on those who use the idea as inspiration to create client-side scripting.

Like, if someone is inspired by bluesman's idea and ends up implementing JS in a Gemini client, it's their decision, not bluesman's.

@bluesman Your idea is very similar to what is essentially PHP, just with JS, although I find two main differences: using it as a service, which is pretty interesting and novel, and the thing I find way more interesting, which is how you've implemented input (basically like forms) with URL parameters.

While I appreciate the scripting stuff for server-side scripting, the way you've implemented input is vastly more interesting for me, both in how it uses URL parameters, and in designing a better API in CGI scripts and servers for more easily creating forms in Gemini.

The idea that you can just specify parameters that you want, and the server will automatically check if the parameter was specified, and if it wasn't, will automatically prompt for the input, is really cool and makes server-side development so much easier!

It has inspired ideas for my own Gemini golang server API.

My only concern is what the response/reaction will be to a more widespread use of URL parameters, since they are kinda bypassing query strings as another way to specify multiple inputs.

Although, the spec never handled URL parameters, so if Solderpunk never intended their usage, then he should have handled their use in the spec ealier, especially since the idea of using URL parameters has been pointed out several times by various people.

@jsreed5 Last thing first. Scriptonite already outputs everything on the page that isn't in a "code block". It does resolve relative links however so it's not a carbon copy.

Right now, Scriptonite is not CGI. It's coded in Java directly in the "GeminiVerticle" of my vert.x server. I do want to release the Gem.X server code but it needs a lot of cleanup. That said, I think Scriptonite could be CGI (and I wish I had thought about that when I started).

I'm pretty sure it could even be a compiled Graal native-image. I did something very similar at my old job a few years back. At some point (because it sounds like a challenge), I'll probably try to get Scriptonite working as a standalone CGI program.

Also, I like the idea of a whitelist/blacklist. Very interesting.

@clseibold I'm glad you were inspired. That's saying something!

The one thing missing from the url parameter scheme is the inability to set the type 10 prompt text (instead of using generic verbiage with the variable name). My solution is to add the url encoded prompt to the variable name.

firstName:Enter%20your%20first%20name;lastName:Enter%20your%20last%20name

Once the vars are populated by the user, a redirect cleans it up for copy/paste/bookmarks, etc.

firstName=Joe;lastName=Smith

I'm also planning to pass in a boolean that the js code can use to check if there's a client certificate. The js code can then make a cert request if it's false. When there is a cert, a Java method to save a String or Map (probably length constrained) will be made available. There will be another method/function to load previously saved data for that client cert. This could be used for saving state without having to worry about packing it all into a url variable.

@bluesman it doesn't "violate the spec" because it uses preformatted text. Then it is fair if I also want style guides and table processing? Adhoc with no cost benefit analysis? Unilaterally by whoever?

@clseibold I might have botched that analogy. I meant if the Atom could no longer squeeze through microscopic openings in the wall due to his new Sumo bod, he might want to rethink that cost benefit tradeoff.

@clarahd It wouldn't violate the spec if I used <script></script> instead of preformatted text. The pages fed into Scriptonite are basically templates that can also be viewed by any Gemini client. Preformatted text makes sense because that's how we view code in Gemini anyway.

I'm not sure about your analogy but if you want table formatting you could probably emulate what Gemipedia does in Scriptonite (or CGI if you have server access). That might be a cool library.

Original Post

I Added Scripting To Gemini — I wrote a gemlog about it. It doesn't break the spec and works in all clients. In a nutshell, it's a service that interprets gemini pages with embedded JavaScript. There are a couple example programs at the link including a simple game. Because scripts have the ability to request data from the user, it's much more useful than first thought.