💾 Archived View for rawtext.club › ~sloum › geminilist › 006713.gmi captured on 2024-03-21 at 16:19:23. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-11-30)
-=-=-=-=-=-=-
Jonathan Lane tidux at sdf.org
Thu Jun 17 17:51:28 BST 2021
- - - - - - - - - - - - - - - - - - -
On Thu, Jun 17, 2021 at 04:34:54PM +0200, ew.gemini wrote:
Well, imho you do not neccessarily need any changes to the
protocol or the gemtext specs.
Noone stops you from:
* writing an article (arbitrary size, consider it big for the
argument)
=
filename.gmi
* compressing this file with xz, say
=
filename.gmi.xz
* adding an abstract which describes the article
=
filename-abstract.gmi
* adding a link to the abstract
=
filename.gmi.xz read more [compressed]
* the abstract is added to your feed and/or index.gmi
The the user will decide whether to follow the link.
The client software might be able to uncompress the downloaded
file and display it similar to LaGrange displaying image as if
they were "inline".
Please bear in mind that the gemini protocol does not even
announce the length of the content to follow.
I would go the same route for extented text where I want to
control the presentation. Use \LaTeX, produce a .pdf file, offer
a download link in an plain/text abstract file, which is
indexed. No need for "complex machinery".
Cheers,
~ew
This is basically how I'd go, although I'd lean towards gzip over xz forbeing much kinder to low-memory systems. Anything that can't be done ona 68030 or an 80386SX doesn't belong in any of the core Geministandards, or even de-facto standards like how to serve compressedgemtext.
See this StackOverflow posting for more details on the justification.
https://stackoverflow.com/questions/6493270/why-is-tar-gz-still-much-more-common-than-tar-xz
-- tidux at sdf.orgSDF Public Access UNIX System - http://sdf.org