Content Processing Plugins (aka mimehooks)

[makew0rld]

This a low-priority feature. It's an idea I have, but not anything that should be implemented over other things.

The plugin system would be similar to #121 configuration-wise, where different executables would be run depending on what mediatype the server data has. In this case, the data would be piped to the programs, and they would output their transformed version of the data to stdout. Whether the executable outputs plain text, gemtext, or ANSI would also have to be specified in the config, or maybe in the first line of the output...

There would need a way to disable these plugins temporarily in the browser. There would also need to be some more things added to the info bar (#142).

Example config

TODO, see #121 for an idea

Example plugins

• Converts some filetype to text/gemtext
  • PDF, EPUB, HTML, Markdown, etc
• Renders images using ANSI color codes
• Translates content (would need access to the lang param somehow)

Multiple Plugins

Multiple plugins can be defined for one mediatype, and will run in the order defined, chaining their outputs. But if one plugin converts away from gemtext, the others ones defined for gemtext should not be run on it after.

Other

• Plugins written by users can be linked to in the wiki, and small scripts could go in contrib/.
• Plugin management system? That might be too much.
• Have 10 second timeout on the total plugin chain

[LukeEmmet]

You might want to have a look at the client side plugins for Dillo - they work similar to client side CGI apps. Might give you some ideas, or even the spec for them might be somewhat portable

https://www.dillo.org/dpi1.html

Also the so called Mimehooks in Lagrange seem to take a similar approach

https://git.skyjake.fi/skyjake/lagrange/raw/branch/release/res/about/help.gmi

[makew0rld]

You're right, this is exactly what mimehooks are. Will update the title, and when this eventually gets implemented then I'll likely follow what Lagrange does, over what I originally wrote.

[jedahan]

for images, might wanna support libsixel. not familiar with go, but when i searched around this looked promising https://github.com/gizak/termui/pull/233/files

[makew0rld]

I'm not really interested in supporting sixel in Amfora, because it can't (or shouldn't) really be used over Gemini. I'm not sure if adding it just so mimehooks can display images really makes sense. They can still use ANSI which should be good enough, though.

[sudobash1]

What do you think about adding ENV variables to be passed to the mimehook (like in normal CGI scripts). An example use case would be a script to detect if the current Gemini page is a GUS search result (via its URL host and path), and if it is then getting the search string (from the query string) and adding colorization to the search result.

[makew0rld]

@sudobash1 As I mentioned above I am using Lagrange "mime hooks" here. As Lagrange defines:

The request's URL is available in the REQUEST_URL environment variable.

I figure that will cover your idea, even though the program has to decode the URL itself. I guess I could also decode the URL for the user and set those variables too? Like SERVER_NAME, SERVER_PORT, PATH_INFO, and QUERY_STRING.

[sudobash1]

I am using Lagrange "mime hooks" here. As Lagrange defines:

The request's URL is available in the REQUEST_URL environment variable.

Aha. That would work fine.

[Seirdy]

As discussed in the mailing list, this would also be useful for tables: rather than make an ASCII table, authors can link to a CSV. A mime-hook can process the CSV into an ASCII table.

[mntn-xyz]

This is a great idea. Would love to make a plugin that uses viu for displaying images in the terminal.

[Seirdy]

On Sun, Oct 10, 2021 at 07:18:24PM -0700, mntn wrote:

This is a great idea. Would love to use viu for displaying images in the terminal.

I've personally seen much better results from Chafa, especially since it can switch from Unicode characters to sixel/kitty/iterm formats/protocols to display images.

-- /Seirdy