A Diatribe Concerning My Experiences with Gopher
This is an article that will collect my opinions concerning Gopher experiences and practices,
primarily those I dislike, with regards to conventions I've encountered and whatnot. I'll update
this article as I have more to write of and feel the want.
Firstly is the presence of the ``i'' item type, the informative type. This type differs from every
other Gopher item type, in that it doesn't denote a resource and is intended solely for display, and
this alone complicates Gopher menu interaction in requiring a special case. Execerbating this issue
is how some Gopher holes omit fields from this item type, as they're entirely meaningless, although
this isn't so bad if one already wants to handle malformed entries. The restrictions of a system
are important, as they show the limits of misuse; I've seen files composed entirely out of this item
type, sans as few as a single entry, and this is the limit to the abuse. This isn't only ugly, but
is also wasteful in information sent and time used processing it. When I first saw this, I was
bewildered, and that bewilderment gave way to disgust. The most egregious use of this item type are
those that are blank and so serve only as presentation control, for clear reasons.
Related to this dislike is a convention I follow and quite like for my Gopher hole. If I have an
article that requires other resources, such as images or program files or even different versions of
the article, the article is represented as a menu in which each entry is present, including the
actual article. A good and recent example is my 2019-06-23 article, which features program and
metadata resources followed by several different versions of the article. I find it odd that, in
telling others of this approach, I've been met with remarks on how clever it is. I'd expected this
to be a basic approach, as it rather quickly came to mind when I was first learning of Gopher and
considering how to represent my articles and whatnot.
Secondly is the ``URL:'' convention for Gopher selectors referring to HTML files. This isn't
necessarily as bad as the ``i'' item type, as there's clear behavior for clients that don't treat it
specially and it's also rather discrete; however, it's still poor. It's trivial to imagine a menu
entry that links to two different resources, based on whether this convention is used or not, to the
benefit or detriment of either. Further, it goes rather directly against the standard document,
which specifically states that selector strings should carry no special meaning; due to this, it
robs people of the ability to begin their selectors with ``URL:'', if they want it to work correctly
in these clients. One can argue that's no issue, but it can go further if tolerated. It would be
easy for people to deem selectors starting with anything to have any special meaning; therein lies
the issue.
My suggestion is to avoid linking to HTML files, in general, without good reason; I link to some
purely because I already have several other versions of an article available; using the ``h'' item
type for this is rather fine, despite being nonstandard, since it can be expected to behave
reasonably, although I wonder how many clients are prepared to accept either the text transfer
method or direct method for HTML files. As HTML can be validated after download and has a
designated item type, I treat it as a direct download with no modifications, as with the ``I'' item
type. Related to this is the belief Gopher selectors begin with ``/'', which is commonly due to the
Gopher URL specification, and using a Line Feed instead of a Carriage Return and Line Feed pair for
Gopher selectors, which are similarly poor and should be reprimanded by a server due to being so
commonplace.
Thirdly is this ``caps.txt'' selector convention. There's positives to having constant resources
that can be used for certain things, similar to the empty selector being the prime menu, but this
convention lacks pleasant aesthetics, I feel. Firstly is the selector itself; why should it
represent with a common file naming; a better selector would be ``capabilities'', as it would avoid
unnecessary abbreviations and wouldn't prefer any particular method of communicating storage.
Secondly it is a format marked by POSIX and so is rather ugly; it contains comment facilities;
Gopher menus support no comments; it is a ``key=value'' format; Gopher has no such format; it is
merely a transferral of an ad-hoc format from POSIX to Gopher. Further, it has unnecessary
facilities for treating selectors as POSIX filenames, to a great detail; there's absolutely no need
for this; if a Gopher hole administrator were to cooperate and provide this ``caps.txt'' resource,
one could just as easily optimize selectors and other such things serverside, instead. It has other
frivolous details, as well. In brief, it seems to go against the spirit of Gopher, I feel. Another
selector I've seen suggested is ``robots.txt'' and I oppose this on the grounds that all WWW
nonsense should be kept out of Gopher.
.