Choosing a Phormat pt. 3 [2021-11-11] ------------------------------------------------------- Keeping the title the same to hopefully make it easier to get threads going between posts... I wanted to callout an interesting observation I read on the gemini FAQ [1] about text vs menu content serving. The observation is that menus are appealing because they allow hyperlinking (with restrictions, like way outdated content types); however, using a menu that is largely text (`i` info types) is a _really_ inefficient way to serve up content, due to the phony selectors and hostnames that come with it! As a practical example, this phlog.txt, including this post, is 7396 bytes, but if it was served as a *.gph file, it becomes 11131 bytes! That's 1.5x the size (~1/3 overhead)! This is also discussed a bit on the gemlog of mozz.us [2], which describes the history of `i`. `i` isn't part of the original RFC, and it _seems_ that the original gopher team weren't thrilled to add it. Of course, `i` won out over plain menus because people like to see a little context... but the "pure" gopher way would be to put said context in a file named ABOUT and be done with it! I think this is all interesting because people are making some really cool gopher apps out of the menu format (like stagit-gopher, for instance). But maybe this is the wrong way to go about things? in the sense that it would benefit from a more flexible format, like text/gemini... Anyways, to go full circle, this revelation about phony selectors reaffirmed my decision to use a plaintext file instead of a gopher menu for this phlog. It's an interesting hypothetical though--is Gopher as useful without `i`? Does the lack of MIME types hinder its future adoption? It does still serve well as a plaintext delivery system, IMHO. And this phlog is a lot of that :) [1]: https://gemini.circumlunar.space/docs/faq.gmi [2]: https://portal.mozz.us/gemini/mozz.us/journal/2021-05-27.gmi