💾 Archived View for rawtext.club › ~sloum › geminilist › 007529.gmi captured on 2024-02-05 at 10:38:32. Gemini links have been rewritten to link to archived content

-=-=-=-=-=-=-

Rethinking the link line

Philip Linde linde.philip at gmail.com

Thu Nov 4 00:01:57 GMT 2021

- - - - - - - - - - - - - - - - - - -

Hi TGL!

On Tue, 2 Nov 2021 09:46:17 -0400The Gnuserland <gnuserland at mailbox.org> wrote:

This flavor forbids any suitable content to be displayed in line even if

the client is capable and should not used to provide link to GMI files.

Note that according to the current specification, clients "MUST NOTautomatically make any network connections as part of displaying linkswhose scheme corresponds to a network protocol". The notion that aclient should automatically make additional requests to display contentin-line is already antithetical to Gemini and is forbidden by the spec.

I suppose that such a feature could be useful for clients that maydisplay resources in-line only upon activating a link, but a common wayto address the problem of downloading such resources in web browsers isto allow saving of the currently open resource or a linked resource viaa context menu. I think that something to that effect could work for aGemini client.

You note elsewhere that this wouldn't be a major breaking change. Icompletely disagree. No existing clients can currently parse "<="links. For that reason, new pages adopting the proposed feature wouldbreak every existing client. Moreover, any content that for any reasoncurrently has a line starting with "<=" with no intention of usingthis feature would incorrectly be interpreted as a link by a clientimplementing this feature, although this seems less likely.

A good work-around is mentioned elsewhere. Give the content somecontent-type that couldn't reasonably be rendered by any client forits ambiguity, like application/octet-stream.

-- Philip