💾 Archived View for rawtext.club › ~sloum › geminilist › 001269.gmi captured on 2020-10-31 at 02:09:57. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2020-09-24)
-=-=-=-=-=-=-
Sean Conner sean at conman.org
Tue Jun 2 22:25:30 BST 2020
- - - - - - - - - - - - - - - - - - -
It was thus said that the Great solderpunk once stated:
In short, there was supposed to be a single, concrete "unit of
interface" with narrow scope that a client author has to decide how to
implement. Variation between clients in how that was done would not
substantially change the overall user experience.
With stuff like data:, feed:, tag:, geo:, and the myriad other
"non-locational schemes", all of this goes out the window. What is a
client supposed to do with all these?
Web and gopher clients already face this issue. Web browsers have solvedthis issue by allowing the user to configure a program to handle an unknownURI scheme. I've registered the "gopher" with Firefox to go through agopher proxy, so I can't see why this can't be an option for Gemini clients. I'm not aware of a scheme like mailcap (for handing of MIME types) for URIschemes, but even a simple:
gopher: my-gopher-client http: firefox https: firefox geo: missile-launcher
will be good enough (and not even mandatory---I'm just throwing out an ideahere).
If I want to write a minimal
client that just knows how to follow gemini:// links and nothing else,
what the heck do I do with a tag: link? Display it to the user, or
hide it?
As a quick solution, how about just display a page with:
I don't know how to handle tag:conman.org,1998-10-16:site Sorry about that.
Done! Ship it!
If I choose to display it using exactly the same code path I
would use to to display a gemini:// link, I need to go out of my way
to make that code path robust against stuff that doesn't make sense for
"proper" links, like there not being a "netloc" component (AV-98
currently silently drops tag: links, for example, because they cause an
Exception when I try to handle them as if they were a "proper" link).
There exists code to parse a URI, whether homegrown or a library. At thevery least, the client can check the scheme portion for "gemini". I'vealready seen URIs for http:, https:, mailto: and data: [1].
If I *do* successfully display them as if they were a proper link and
the user tries to follow one, what is supposed to happen? Assuming I
fix the aforementioned problem, AV-98 will say "Sorry, no support for
tag", because it fills out a template that I designed thinking of cases
like "Sorry, no suport for ftp", which most users will understand. *I*
would be very confused by a "no support for tag" message, I'd think
"What, there *are* no tags in Gemini, what's going on here?".
I've already mentioned Firefox, but Lynx gave me "Alert!: Unsupported URLscheme!" when I tried using a gemini: link on a webpage. Don't sweat it.
So, I'm not sure how to proceed here. People should feel free to
experiment with possibilities, because informed decisions are better
than uninformed ones. But I would advise people not to get fiercely
attached to any idea of how non-locational URLs might work in Gemini.
It's uncharted territory.
I think your concern (or fear) is overblown here. Outside of
http: https: mailto:
I think other URI types on the web will fall deep into the 0.56% of linksthat aren't the above.
-spc
[1] The Gemini Client Torture Test