💾 Archived View for mozz.us › journal › 2019-08-08_on_gRFC_0001.gmi captured on 2023-03-20 at 17:57:31. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2020-09-24)
-=-=-=-=-=-=-
Published 2019-08-08
I've read solderpunk's latest post on two-digit status codes and have updated my server accordingly. I don't feel strongly enough about it to take a stance either positive or negative. It's fun to be on the bleeding edge though!
SPC saw my post about how text/gemini should reflow text, and he pointed me to the RFC that recently published:
gemini://gemini.conman.org/gRFC/0001
Thanks for the heads up! It's nice to see that somebody else has also though about this. Here are some comments that I have about it:
text/gemini; charset=ISO-8859-1
The section about charset makes perfect sense to me and mimics what I already have implemented on my server. I can't think of a particularly good reason to use a non UTF-8 encoding, but I don't see any reason to prohibit it. If you're using a system library that can handle UTF-8, it should be trivial to switch out the encoding when reading a file.
text/gemini; charset=US-ASCII; format=flowed
I’m not super excited about the idea of adding a “fixed”/“flowed” parameter.
What will likely happen is that some servers will end up using the “fixed” format exclusively, and some servers will use the “flowed” format exclusively. That creates a rift between the two spheres of servers, kind of like the divide that WWW has between responsive websites and non-responsive websites.
What would I do if I was writing a mobile client and the server responded with a “fixed” format menu? Do I refuse to serve the page? Do I cutoff the text at ~50 characters wide and force the user to scroll back and forth horizontally? Both of those are pretty crummy experiences for the user.
Using the "flowed" format exclusively reduces complexity for gopher clients, and servers can always revert to "text/plain" if they want to show off some ASCII art or monospace formatted documents.