Index  Comments

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.