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
