support multiple link types beyond html and gopher #69

New Issue

cmccabe · 2019-12-21T11:24:15Z

cmccabe commented

2019-12-21 11:24:15 +00:00

I think I posted as a tangential thought in another issue, but I can't find it now.

The idea is to expand linkulator beyond http and gopher links, to also support ssh, curl, finger and probably others.

Some examples:

ssh torus@ascii.town
curl yourCityName@wttr.in
finger [that choose-your-own-adventure url]

This would entail modularizing the browser support because no one browser supports all of these protocols. The module change should include protocol/browser pairs, so that linkulator knows to call browser-A when a link of protocol-A is seen.

The representation of protocols is a bit tricky, but would require that each has a regex that uniquely identifies protocols based on the input URL. It may be as simple as:

contains http:// or https:// = browsers like lynx
contains gopher:// = browser like bombadillo
contains finger [space] address = browser like bombadillo
contains ssh [space] address = ssh client
contains curl [space] prefix@address = (hmm, maybe need an additional handler for ones with a variable prefix)

I think I posted as a tangential thought in another issue, but I can't find it now. The idea is to expand linkulator beyond http and gopher links, to also support ssh, curl, finger and probably others. Some examples: * ssh torus@ascii.town * curl yourCityName@wttr.in * finger [that choose-your-own-adventure url] This would entail modularizing the browser support because no one browser supports all of these protocols. The module change should include protocol/browser pairs, so that linkulator knows to call browser-A when a link of protocol-A is seen. The representation of protocols is a bit tricky, but would require that each has a regex that uniquely identifies protocols based on the input URL. It *may* be as simple as: * contains http:// or https:// = browsers like lynx * contains gopher:// = browser like bombadillo * contains finger [space] address = browser like bombadillo * contains ssh [space] address = ssh client * contains curl [space] prefix@address = (hmm, maybe need an additional handler for ones with a variable prefix)

sloum commented

2019-12-21 16:49:59 +00:00

I think it would be great if linkulator could handle any url type. Bombadillo can support:

telnet
finger
gopher
gemini
local files
http(s)

The last one is configuration based. For rawtext you could build it with the config setting webmode: lynx. Then it will be on by default for system users.

That leaves curl and ssh. It should be pretty easy to sub-process ssh. I dont know about that particular format for curl so not sure about that. wget could be convenient for some stuff if people want to download.

For finger to work w/ bombadillo the address should be formatted as: finger://[username@]HOST. If you enforce a scheme on every url (ssh://, local://, gopher://, finger://, etc) it makes the links extremely clear and makes it easy to pass them or parse them.

I think it would be great if linkulator could handle any url type. Bombadillo can support: - telnet - finger - gopher - gemini - local files - http(s) The last one is configuration based. For rawtext you could build it with the config setting `webmode: lynx`. Then it will be on by default for system users. That leaves curl and ssh. It should be pretty easy to sub-process ssh. I dont know about that particular format for curl so not sure about that. wget could be convenient for some stuff if people want to download. For finger to work w/ bombadillo the address should be formatted as: `finger://[username@]HOST`. If you enforce a scheme on every url (`ssh://`, `local://`, `gopher://`, `finger://`, etc) it makes the links extremely clear and makes it easy to pass them or parse them.

cmccabe commented

2019-12-22 10:37:00 +00:00

Do you think it is best to extend linkulator's config file to have settings for each of the supported protocols? Or is it better to simply support the protocols and use a single browser (Bombadillo) to handle them?

sloum commented

2019-12-22 17:13:22 +00:00

Hmmm... I'm torn. Bombadillo requires specific structure to URLs to get them to load, but it should be fairly standard-ish. The systems mime db should actually do the job fairly well and opening based on defaults for a mime type might be a way to go.

Hmmm... I'm torn. Bombadillo requires specific structure to URLs to get them to load, but it should be fairly standard-_ish_. The systems mime db should actually do the job fairly well and opening based on defaults for a mime type might be a way to go.

asdf added the

future release

enhancement

labels 2020-01-09 03:12:48 +00:00

asdf referenced this issue

2021-08-12 09:35:59 +00:00

Viewing gemini:// links from linkulator #102

samhunter referenced this issue

2021-08-12 10:25:54 +00:00

Viewing gemini:// links from linkulator #102

asdf commented

2021-08-19 07:04:29 +00:00

Prompted by #102 by @samhunter, looking at this in more detail - these are the schemes actually in use:

scheme	%total
'https'	75.71%
'http'	14.98%
''(empty)	4.45%
'gemini'	2.43%
'gopher'	1.62%
'telnet'	0.40%
'finger'	0.40%

The original functionality allows the user to open http:// and gopher:// links with a single browser application. URLs with different schemes, like gemini://, can be opened, with a warning.

The proposed functionality is to allow the user to add individual schemes to their configuration, specifying which program should open URLs of that scheme.

I propose this works in the following way:

A new mandatory section [URL Handlers] will be added. New mandatory options to be added to this section are http, gemini, gopher, telnet and finger. These options are empty by default.
When opening a URL, the program attempts to match the scheme to the name of an option in the [URL Handlers] section. If it is found, it will try to call the value of that option, with the URL as an argument.
If a scheme is not configured, the user will be prompted to change their configuration and the URL will not be opened.
Additional optional scheme options can also be set and will be handled as above. These will be written to configuration on exit.
http is a special scheme option, and its value will be used when opening URLs with http and https.

Examples:

[URL Handler]
http = lynx              ; the value of this option opens both http and https
gopher = /usr/bin/gopher ; full path to a program is acceptable
gemini =                 ; empty value is acceptable for mandatory options
finger = 
cool = cool              ; a non-mandatory scheme

To aid with the transition, temporary functionality will be added:

The existing [User Settings] section and browser option will be read, but not written on exit.
If the older section and option are read, but the new section is not, the new section is created and options http and gopher have their values set to whatever the older option had.
If it's too hard, the functionality may not be implemented.
The functionality will be removed in the next version of the application.

Some alternatives to the above proposal:

could do http and https as separate options
this breaking change could be a good excuse to save the config file to $XDG_CONFIG_HOME too. The data file will remain where it is.
if the $BROWSER environment variable is set, and no values are configured for the http option, the $BROWSER environment variable is used. Or, the value of http is set to "$BROWSER" instead to make it clear this is the value being used.

Prompted by #102 by @samhunter, looking at this in more detail - these are the schemes actually in use: | scheme | %total | | -------- | -------- | |'https' | 75.71% | |'http' | 14.98% | |''(empty) | 4.45% | |'gemini' | 2.43% | |'gopher' | 1.62% | |'telnet' | 0.40% | |'finger' | 0.40% | The original functionality allows the user to open `http://` and `gopher://` links with a single browser application. URLs with different schemes, like `gemini://`, can be opened, with a warning. The proposed functionality is to allow the user to add individual schemes to their configuration, specifying which program should open URLs of that scheme. I propose this works in the following way: * A new mandatory section `[URL Handlers]` will be added. New mandatory options to be added to this section are `http`, `gemini`, `gopher`, `telnet` and `finger`. These options are empty by default. * When opening a URL, the program attempts to match the scheme to the name of an option in the `[URL Handlers]` section. If it is found, it will try to `call` the value of that option, with the URL as an argument. * If a scheme is not configured, the user will be prompted to change their configuration and the URL will not be opened. * Additional optional scheme options can also be set and will be handled as above. These will be written to configuration on exit. * `http` is a special scheme option, and its value will be used when opening URLs with http and https. Examples: ```ini [URL Handler] http = lynx ; the value of this option opens both http and https gopher = /usr/bin/gopher ; full path to a program is acceptable gemini = ; empty value is acceptable for mandatory options finger = cool = cool ; a non-mandatory scheme ``` To aid with the transition, temporary functionality will be added: * The existing `[User Settings]` section and `browser` option will be read, but not written on exit. * If the older section and option are read, but the new section is not, the new section is created and options `http` and `gopher` have their values set to whatever the older option had. * If it's too hard, the functionality may not be implemented. * The functionality will be removed in the next version of the application. Some alternatives to the above proposal: * could do `http` and `https` as separate options * this breaking change could be a good excuse to save the config file to $XDG_CONFIG_HOME too. The data file will remain where it is. * if the `$BROWSER` environment variable is set, and no values are configured for the `http` option, the `$BROWSER` environment variable is used. Or, the value of `http` is set to `"$BROWSER"` instead to make it clear this is the value being used.

asdf referenced this issue

2021-08-19 07:45:08 +00:00

Viewing gemini:// links from linkulator #102

asdf removed the

future release

label 2021-08-19 08:03:51 +00:00

asdf added the

this release

help wanted

labels 2021-08-19 08:32:07 +00:00

Sign in to join this conversation.