| # What is gopher?
|
| This file serves to attempt to disprove common misconceptions about gopher, here
| goes.
|
| {1} Gopher is: a filetype-agnostic transfer protocol.
|
| For a client to request a file, it sends a string like so:
|
| path<CR><LF>
|
| To the server - <CR> is a shorthand for a carriage return, and <LF>
| is a linefeed, aka newline. The "path" could theoretically be
| anything, however almost all gopher servers expect a unix-like path.
| For example:
|
| /docs/gopher.txt
|
| The server then starts sending the *unmodified* contents of the file.
| *unmodified* does not mean the server can't modify the file - it
| means the client is not expected to un-modify a file when recieved,
| so if the server modifies the contents to, for example, compress the
| file, the client will not have any way to expect that and will choke.
|
| When the server is finished sending the file, it sends the following:
|
| .<CR><LF>
|
| This is so that the client knows it has recieved the full file, with no
| truncation.
|
| {2} Gopher is not: plaintext only
| see the above paragraph
|
| {3} Gopher is also: a menuing system
|
| A menu is a set of "links" or "pseudo-links".
| Menus use the following form:
|
| <t><desc>\t<path>\t<hostname>\t<port>
|
| <t> == A "type". Types specify to the client what to expect when
| following a link, for example '1' means a "directory" or
| gopher menu. Types must be one character long.
| <desc> == A description of the link, can contain any character
| except an ascii tab.
| <path> == The same "path" as described in the first paragraph, can
| contain any char except a tab.
| <hostname> == The hostname of a server, can be dns based, a direct ipv4,
| ipv6, etc. This is only limited by the capabilities of the
| client.
| <port> == The port of a server.
| \t == An ascii tab character.
|
| To link to a resource on the same server, the <hostname> and <port> must
| be the server itself - many gopher servers provide a way to fill in this
| info for you. For example the gophernicus server allows you to omit the
| <hostname> and <port>, appending internally defined values instead.
|
| The geomyidae server takes a wildly different approach. geomyidae uses
| it's own gophermenu syntax, to see more details, look at the man page
| [1]. To link internally, type the literal words "server" or "port" in a
| link. For example, if running on haydenvh.com with port 70, this:
|
| [1|internal resource|/file.txt|server|port]
|
| Will be translated to:
|
| 1internal resource file.txt haydenvh.com 70
|
| (note, instead of using actual tabs I use spaces for the examples).
|
Text | Follow this link to see the "gph" source of this page
Text | Here is a list that shows canonical and common types.
|
Text | [1]
|
| {4} Gopher is not: purely static
|
| This is a very flawed misconception. The gopher protocol does not in
| *any* way prevent dynamic content. In fact, the majority of servers
| support dynamic content generation by default, and do this simpler
| compared to most web servers.
|
| Dynamic generation varies from server to server, as there is no standard
| for this - at first this seems like a negative, but it ultimately means
| more freedom for the person creating the content, as they can choose a
| server that is right for them.
|
| Many servers generate dynamic directory listings - this is likely to
| happen even if you don't create any explicit "dynamic files/menus".
|
| Gopher also supports a way to input text to a server. This is done by
| appending a tab, followed by the query to the "path" sent to the server.
|
| Another example of dynamically generated content defined by the server
| itself is web redirects. The server here sends the client a html file
| designed to redirect to the specified web page.
|
| {5} Gopher has: a uri scheme
|
| gopher://<host>[:port]/<type>[path][\tquery]
|
| Anything wrapped with angle brackets <> is required, anything within
| square brackets [] is optional. The "port" defaults to 70, if no path is
| given, the server sends the "root page", which most of the time contains
| links to submenus or content. The "query" does not default to anything.
|
| {6} Gopher does not need: mimetypes
|
| This is a controversial statement, and this point is mainly my opinion.
|
| Mime-types are primarily designated based off of the extension given to
| a file path. Therefore it seems resonable for the *client* to be able to
| look at this. In fact, it is possible for clients to completely ignore
| the extensions and implement their own ways of handling files, such as
| by using file(1) to inspect the contents of a file to determine what to
| do with it. This is more programmable, as the server doesn't tell the
| client what to do.
|
| {7} Gopher does not have: text formatting
|
| See the following point.
|
| {8} Gopher servers do not: tell clients how to render content
|
| There is no native text formatting language like HTML on gopher.
| Instead, the client and/or the user can define what is displayed. This
| is a similar approach to what email clients do with plaintext mail, or
| irc clients do with messages.
|
| Here [2] is a screenshot of a fork of `cgo` [3], a screenshot [4] with
| `lynx`, and a screenshot [5] of `curl`, which doesn't render content at
| all.
|
| Many writers of gopher content use `Markdown` - a text formatting
| langauge based of human readable email formatting. This makes sense as
| it is easily parsable by humans, but could allow for clients to
| implement a "Markdown mode" in which they render it. There is simply no
| end to client customizability.
|
Img | [2]
Dir | [3]
Img | [4]
Img | [5]
|
| To circumvent this limitation, many people get creative, using text,
| symbols and whitespace to lay out their content, or even draw things.
|
| {9} Gopher is: simple
|
| I hope you have already gotten this point, as it is the #1 thing I want
| you to take away from here.
|
| By being simple and stupid in design, it is easy to shape gopher into
| forms. A basic gopher client capable of fully rendering content is a
| very manageable project for any person who has basic understanding of
| programming. This is very much unlike the web, where there are only
| really a few web "engines", with most browsers/clients only differing by
| the user interface hastily glued onto the "engine". This should be
| unnaceptable to the end user.
|
| Instead of making it easier to use the web, the majority of new
| technologies convolute it further, and add another box to the already
| huge checklist of standardized features, instead of rubbing out and
| redoing bad design decisions.
|
| {10} Gopher is also: easily convertable to HTML.
|
| This is a fun little side note. I made a http server [6] a while back
| that can convert standard gopher content, and geomyidae content to HTML.
| This is not the only such proxy, but it is *the* server that is designed
| to do so. I have not yet seen anyone take such an approach, as of 2020,
| so I am probably the inventor of this idea :) Gopher menus are easily
| awkable.
|
| I use this mainly so I can show web peasants information that I have
| exlusively written for gopher, it emulates my favourite (and forked by
| me) client, cgo [3].
|
Text | [6]
|
| ---
|
| If you are running my fork of `cgo`, use the = command here to pagerize this
| file.
|
| --
| hhvn <hayden@haydenvh.com>
This page was generated via hhttpd (http://haydenvh.com/scripts/other/httpd.sh) from geomyidae gopher content.
You should be using gopher directly, if possible.