a space case for transparent gemtext compression

Peter Mucha ptmucha at gmail.com
Sun Jun 20 09:07:10 BST 2021


I think a lot of aspects were discussed already but let me add my two
cents, coming from a slightly different perspective (webapp developer):

It was proposed to have two links, one to the gmi, one to the compressed
version. This is basically what the accept header in html is for, just
deferred to the user. And you look for some kind of signalling to the
server that you want a specific representation of a resource. You propose
file-extensions which by itself is another convention you introduce here
(or additional protocol). URLs don't know about file extensions. Webapps
don't know about file extensions.

Abstractly speaken: if we don't have a good way to signal to the server
what kind of representation of a resource I want, we should drop this. We
should not make up conventions artificially. Maybe they will emerge
naturally anyway.

One thing I miss in the discussion: I see comments about writing files and
serving files. I got by now that this is pretty common in Gemini space but
there are servers, serving generated content (blogs or games or whatever)
and so no assumption about how big files are should be made...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20210620/a1dbcf5b/attachment.htm>


More information about the Gemini mailing list