[Top] [All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
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.
- 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
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
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
- 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?
- 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
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...
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)