💾 Archived View for rawtext.club › ~sloum › geminilist › 006718.gmi captured on 2023-11-14 at 09:09:10. 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

Thomas Karpiniec tkarpiniec at icloud.com

Fri Jun 18 00:26:05 BST 2021

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

On 18 Jun 2021, at 6:27 am, Francis Siefken <fsiefken at gmail.com <mailto:fsiefken at gmail.com>

wrote:
Alternatively one could reconfigure it client side to automatically decompress and display client side, with the back button or key working - but this you cannot enforce as the one serving the gemini capsule.

Right. There is nothing strange or wrong about returning compressed data with a suitable MIME type, and it is logical for a client to pass the binary blob on to the default extractor app, as happened in your test.

To me, this line of the spec rules out decompression as a feature of the Gemini client itself:

Response bodies are just raw content, text or binary, ala gopher. There is no support for compression, chunking or any other kind of content or transfer encoding.

As with any home-grown extension you can certainly implement it for your own purposes. I just don't see a way forward for widespread compression support when it's been explicitly scoped out.

Since you mentioned 1200 bps and radios in your original post, I will remind the list that Gemini is unsuitable as a protocol for any amateur radio operations due to the encryption. I used gopher for that purpose instead.

Cheers, Tom-------------- next part --------------An HTML attachment was scrubbed...URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20210618/d59f1b4c/attachment.htm>