💾 Archived View for rawtext.club › ~sloum › geminilist › 006765.gmi captured on 2023-09-28 at 16:39:46. 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

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 twocents, coming from a slightly different perspective (webapp developer):

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

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

One thing I miss in the discussion: I see comments about writing files andserving files. I got by now that this is pretty common in Gemini space butthere 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>