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.
.