a space case for transparent gemtext compression

[Jonathan Lane]

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 for
being much kinder to low-memory systems.  Anything that can't be done on
a 68030 or an 80386SX doesn't belong in any of the core Gemini
standards, or even de-facto standards like how to serve compressed
gemtext. 

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.org
SDF Public Access UNIX System - http://sdf.org