💾 Archived View for rawtext.club › ~sloum › geminilist › 007532.gmi captured on 2024-03-21 at 15:46:45. Gemini links have been rewritten to link to archived content

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

Rethinking the link line

The Gnuserland gnuserland at mailbox.org

Thu Nov 4 16:31:00 GMT 2021

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

Hi Philip,

it is so cool that you guys were able to redefine in such technical fashion what I felt from a simple user stand point!

Eventually it looks like it wasn't just bikeshedding... ;-)

I hope this topic may go forward!

Thanks,

TGL

On 11/3/21 20:01, Philip Linde wrote:

Hi TGL!

On Tue, 2 Nov 2021 09:46:17 -0400

The 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 NOT

automatically make any network connections as part of displaying links

whose scheme corresponds to a network protocol". The notion that a

client should automatically make additional requests to display content

in-line is already antithetical to Gemini and is forbidden by the spec.

I suppose that such a feature could be useful for clients that may

display resources in-line only upon activating a link, but a common way

to address the problem of downloading such resources in web browsers is

to allow saving of the currently open resource or a linked resource via

a context menu. I think that something to that effect could work for a

Gemini client.

You note elsewhere that this wouldn't be a major breaking change. I

completely disagree. No existing clients can currently parse "<="> links. For that reason, new pages adopting the proposed feature would

break every existing client. Moreover, any content that for any reason

currently has a line starting with "<=" with no intention of using> this feature would incorrectly be interpreted as a link by a client

implementing this feature, although this seems less likely.

A good work-around is mentioned elsewhere. Give the content some

content-type that couldn't reasonably be rendered by any client for

its ambiguity, like application/octet-stream.