Gopher enjoys 30 years of software support for just about every platform imaginable, from Windows and MS-DOS compatibles to Unix workstations, the classic Mac OS to OS X, Amiga, RISC, NeXT, OS/2, to gateways and proxies that can be accessed directly over the Web. Not all of these clients are equivalent though; there is no "official" Gopher client, so all clients slightly differ in their handling of edge cases, errors, and quirks in server setup.
As a companion to my reviews of Gopher clients, here's some features you should mind in getting the most accurate, enjoyable Gopherspace browsing experience.
Table of contents
These are features that I'd consider necessary to even bother using a specific client.
RFC 1436 defines 14 item types in a menu; lines of plain text were not one of them. Naturally, as some servers wanted to get a little fancier with how they presented their materials, an improvised item type, the informational selector, was developed. This is a selector in a menu with an item type of
i, which appears not as a clickable link, but as plain text inline with the menu itself.
Some of the stingier, more basic clients don't support these. The better ones display them as clickable links that return errors. The worse ones don't display them at all, leading to incomplete menus without context.
Arbitrary port support
In computing, a port is a number that's used to make sure different kinds of internet traffic get routed to the right applications. If you're grabbing your email while also playing Quake, email might come in over port 25 while the game might be on port 27500. This keeps your email data separate from your game data so neither your computer nor the servers get confused.
Gopher data is often sent over port 70. As such, Gopher clients are sometimes hardcoded to only work on port 70. Note that I said often, however. Some servers, either because of the admin's preferences or for debugging purposes, will use another port. (In my tests, I use FrillerWorks' server, which is on port 7070.) As such, these clients can't connect to these servers. A good client should allow connection to a server on any port, not just 70.
Full URI compatibility
RFC 1436 says nothing about URI schemes for Gopher; the later RFC 1738 does specify a standard format for Gopher URLs, but this is a less commonly circulated memo (and even less common is RFC 4266, which expands on it). Gopher URLs roughly take this form:
A real world example:
Commonly, it's the item type (in our example,
0) being encoded in the string itself that'll confuse a client. While it's not common to find clients that can't handle these URLs, they are out there and they can make one far more of a hassle to use. (My recommended standalone Gopher client, Gophie, ran into this problem until its maintainer graciously fixed it in the 1.1 release.)
While these aren't strictly necessary, they're good for completeness sake. These take a client from "usable" to "preferred" in my eyes.
CCSO is a protocol often associated with Gopher, though not directly related to it. CCSO dates back to Gopherspace's origins in academia, where contacting people was central to your work. It's a digital phone book of sorts, and on Gopher's end, you'd be able to punch in a name or a phone number and look up the full contact information of the person that you're trying to reach.
A Gopher client that supports CCSO will also support any other form of search, including Veronica-2 and Gophew, which are directly related to browsing Gopherspace. That's not to say that all non-CCSO clients also fail to support search, but a large number of them do.
Gopher+ is a minor, short-lived extension to the protocol that supports sending metadata, such as dates and descriptions, along with menu items. Gopher+ is so minor that I currently don't know of any Gopher+ servers or capable clients in the wild. As such, the focus is on tolerance. A client that, even if not Gopher+-capable, can handle a Gopher+ server is a very good one indeed.