[gopher] Gopherness

[Jay Nemrow <jnemrow@xxxxxxx>]

I have been thinking about the whole idea of Gopherness and how that 
relates to how we set up our gopher servers, what "extensions" we choose 
to make to the protocol, and how the "future" Gopher should look.

Of course, most of you know that I have a historical perspective on 
this, like many of you do.  My first experience with Gopher was through 
a university shell account in 1992.  My client was the old gopher one (I 
think UMN created it) used over a serial modem line, just like the one 
that is accessible through telnet at quix.us or via phone at 
1(575)461-0077.  Although I could be accused of being nostalgic, I hope 
I can avoid that by saying that my content is modern (as in relatively 
up-to-date) and most of it is unique (not found elsewhere).  These are 
two aspects (among many) of a term that I am creating called 
"Gopherness", which will hopefully encompass everything that Gopher was, 
is, and will hopefully become.  If you find this cocky, I haven't even 
really gotten into it yet!

I will harken back to the past often enough to define what Gopherness is 
and what makes something "gopherly" or ungopherly".  I, of course, 
welcome feedback on all of this and will hopefully not use this as a 
personal springboard by including only my own information (such as 
telnet address and modem number).  Gopherness also doesn't define just 
the way I do things, as I can assure you that I currently do several 
"ungopherly" things with my server which I must work to remedy.  Most of 
these "ungopherly" things are habits that many of us have picked up over 
the years, predominantly from following trends incidental to the 
World-Wide-Web, which, by its nature, is most "ungopherly".

I hope I don't offend too many people by using examples of common usage 
in clarifying "gopherly" and "ungopherly" behavior.  If it helps at all, 
I will use my own server for several examples of practices and ideas 
that are not in keeping with "Gopherness".  Although I do wish to repent 
and get more "gopherly", I have only begun such a process.

Ungopherly:

- Putting "up" or "previous menu" items in menus which points into your 
personal "data island".
This is www behavior, which is server-centric by nature and tries to 
make you stay in a "silo" or island that a webmaster or company 
controls, right down to how the "site" looks on your screen.  "I will 
find that at the Google site."  One of the first selling points of 
Gopher was that you didn't need to know what server was giving you the 
menu/text/file you were working with.  It all felt like one big mass of 
menus and information and it was presented to you the same way, the way 
your client displayed menus, text, and files.

- Only Using Menu Items that Point to Root Menus at other Servers
This is www behavior that encourages people to access a "castle" of data 
only through the front door.  www people sometimes even force access to 
their information this way, so a person can get the "whole experience" 
or to prevent "stealing" their precious data.  Gopher is composed of 
menus that come from hundreds (okay, now it is dozens) of sources.  It 
is more like a road system where there are many ways to get to a 
destination and there is no mechanism that punishes "unauthorized" 
routes.  Gopher says that if you put data on your Gopher server, you 
want everyone to be able to access it without restriction and through 
whatever menu structure that presents itself.

- Adding an Endless Array of New Item Types for Every New Thing that 
Comes Along
This is a www disease that has spread to gopher.  Browsers (and their 
associated plug-ings and "readers") grow exponentially eating up storage 
space and connectivity bandwidth.  This is because browsers are "smart" 
clients that access essentially simple servers.  Most of the 
intelligence is in the ever-bloating client.  Gopher is (or should be) 
the opposite:  a smart server that contains all the intelligence and a 
relatively simple client that only moves among menus, displays ASCII 
text, and downloads files.

- Creating "Wrappers" for Things that Don't Easily Fit the 
Menu/Text/File Model
This is just laziness oftentimes.  If something cannot be rendered to 
menus or texts simply, it get shoved into a binary file.  MIME is a 
wasteland of different reditions of often common things, requiring 
seperate readers for each type.  Most PDF files are predominately text 
with a few pictures or other such things in them.  A Gopher rendering 
would be a menu that points to a text (that contains the PDF text) and 
binary files (that contain pictures and the other things from the PDF 
file), which allow a person to read the text without dealing with the 
pictures until the person deems it necessary.  No "reader" needed until 
you want to deal with pictures, for example. The Gopher server (as the 
brains of the operation) should convert such binary things into common 
formats that can be read by the gopher client itself or by a few small, 
launched "reader" programs.  You can put up the PDF file as a possible 
download, but don't make it something everyone has to download to figure 
out if they need it - that is bandwidth waste.

- Bandwidth Waste
Gopher was created in a time when access to information came over slow 
modems connected to phone lines.  Gopher should be respectful of people 
who either choose to or must access things this way.  Browsers and 
always-on broadband connections at fixed fees have taught people that 
there is no penalty to being wasteful of bandwidth.  It pains me to see 
someone put up a video of a radio show on YouTube (audio feed would have 
been less wasteful) or worse a video of someone reading a passage of a 
book aloud (not only could this be audio, but it could be rendered as 
text from the book and fit into a few kilobytes rather than several 
megabytes)!

- Worrying about How Things Look on the Client Side
Another www disease.  The only big seperation between browsers is how 
they render the formatting information given to them.  "This site was 
designed to be viewed with Internet Explorer."  I spent hours dolling up 
my web pages in the old days.  This is what happens when how something 
looks is much more important than content.  The modern world-wide-web is 
increasingly content-free, more a springboard for advertisements and 
snappy graphics or a cool interface.  Gopher can save you from all of 
this because it handles everything about the same way - I mean how many 
ways can you display an ASCII text?  Although there is some interest in 
creating Gopher clients that make the menus look cool or include a 
billion helper apps (and item codes)(I like the mental picture of gluing 
four more legs on a gopher and try to pass it off as a replacement 
spider [the web, do you get it?]), spending time on this takes away from 
what makes Gopher special - a maniacal obcession with content for its 
own sake.  Gopher never was pretty but it was very informative.  Which 
would you rather have?

Gopherly:

- Clients should be Created for every Computer
The whole point of providing information to others is to make it as 
accessible as possible.  Having to make choices in computers based on 
the fact that "it runs the web browser I need to use" is a sad state. 
 If I want to view local sports scores on my old c64, that should be 
possible.  Unlike bloated web browsers, gopher clients are available for 
most computers ever made.  If there isn't one for your computer, the 
Gopher protocol is simple enough that a person with very modest 
abilities in programming (BASIC will do in a pinch) should be able to 
create a client that can access EVERYTHING in Gopherspace.  This should 
be the goal - Everyone can see Everything.

- Rendering Everything into Either a Menu, an ASCII Text, or a 
Downloadable File
The miracle of the gopher client is that it is so easy to implement. 
 Almost every computer ever produced has a gopher client or someone of 
modest skills could create one that performs all the basic functions. 
 This is true because the Gopher server contains all of the intelligence 
required to feed content to a client.  The server has the task of 
"rendering" information into either menus, texts, or files, or into 
combinations of any of these.  Any basic gopher client can then access 
this information without the need of a helper application or "reader". 
 "Render" means to take something to its simpliest form.  Most Microsoft 
Word documents would be "rendered" to ASCII text, for example.

- Rendering Everything Else to a Handful of Established Types.
How many different video file formats are there?  Thousands?  Each one 
requires a "reader" to use, often a different reader for each format. 
 The gopher server might render different formats to an established 
common one, so that the Client has only to deal with one reader and one 
different item type.  For example, all pictures would be rendered as 
jpegs and it would be assumed that the Image file type referred to a 
jpeg.  The person running the server that has pictures on it would 
simply convert all images to jpegs before putting them on the server or 
they would have a script on the server that would do the conversion for 
them.  In the spirit of Gopher, these different formats (picture, audio, 
video, etc.) should probably be the simpliest formats to reduce the 
complexity of creating client or helper applications - the client is 
supposed to be simple to make.

-The Server Does All the Work
A Gopher server does all the labor of creating menus, texts, and files 
for the very simple Gopher clients to use.  The *fun* in "Gopherness" is 
not in creating interesting new (read more featureful) browsers or 
helper apps/add-ins (like for www), it is in creating new and 
interesting content and rendering engines at the server!  Want to create 
a menu with all the latest arrests for Paris Hilton (here come the 
lawyers)?  Create a script to access several news sites and render these 
into menus and texts (heck, you will want some pictures as well...) to 
serve out to clients.  If I want a pretty client with all the bells and 
whistles, I would just abandon Gopher and get Opera or Flock or 
something like that (oh, yeah, everyone already did that!).  Gopher's 
strength is always in the server and what interesting stuff gets served, 
with a goal that your menus will be included on everyone's root menu!

- Use Menu Titles that Stand Alone
I know most clients now handle the i item type, which gets used as an 
information line under more purposeful menu items.  Some older (read 
browser-based) Gopher clients ignore i (which is good behavior), but if 
your menu title doesn't make sense without the info lines that go with 
it, your menu doesn't make sense.  Remember that i item type was a newer 
convention and that no one has to support it.


I am sure there could be a lot more here and I encourage everyone to 
contribute to this.  In reading some of the discussion here, it seems 
everybody needs a bit of an idea of what Gopher is going to be about and 
what guiding principles  fit "Gopherness" that we need to cling to as we 
sail in the small dinghy of Gopher in waters crowded with huge Web 
container boats.  We can't afford to act like them...

Jay Nemrow
Quasi-Indefatigable Xenolith
gopher://quix.us  telnet://quix.us  (okay, http://quix.us as well)
Dial-up QuIX Gopher: 1(575)461-0077 (8-n-1 term=vt100)
email:  jnemrow@xxxxxxx