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

View Raw

More Information

⬅️ Previous capture (2021-11-30)

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

<-- back to the mailing list

a space case for transparent gemtext compression

PJ vM pjvm742 at disroot.org

Sat Jun 19 12:13:20 BST 2021

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

A bit of a recap and my thoughts:

Some people should reflect on what they said in this discussion and howthey said it: what parts of it were helpful and what parts weren't.Maybe they can avoid a similar mess in the future. Moving on...

On 19/06/2021 10:59, Stephane Bortzmeyer wrote:

* how the end user of a browser without compression support will know
in advance if the file is compressed or not? From the file extension?
It is not always present.

I expect authors would indicate this in the link text. So:

=

article.gmi my article=
article.gmi.gz my article (compressed version)
* today, every browser can read every Gemini file. Your proposal
seems to imply that some users will now see only a part of the
Geminispace, the uncompressed one. This is the same problem we have
when trying to use the Web with lynx or dillo: we can see only a part
of it.

First of all, people are already serving PDFs &c via Gemini, which isalso something that Gemini is intended for. So already, not the entireGeminispace is visible from within the Gemini client.

Secondly, I'd expect that authors offer a compressed version only inaddition to the uncompressed version, not as a replacement. I don't seethis feature becoming nearly popular enough for authors to start doingthe latter.

-- pjvm