[gopher] A Sunday morning diatribe
[Top] [All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
Please allow me to indulge in a bit of Sunday morning musing and
Comparing the WWW to Gopher is "wrong thought". It starts the conversation
from a faulty predisposition and it never entirely breaks free. The WWW was
designed in isolation from, and is in no way associated with, Gopher. Even
saying that the WWW does things better than Gopher is a misnomer. Yes people
may claim that for the "modern" WWW, but that isn't how the WWW looked in the
beginning when Gopher was king... See for yourself by viewing your website
using an emulator of the original pre-Mosaic Web client (yes, contrary to what
the revisionists say over and over again, there were clients before Mosaic) at:
Gopher was developed by a University as a way to provide their students a way
to access the Universities data in a manner that was superior, both in
presentation and safety, to the "File Transfer Protocol" (FTP). Gopher is
actually a SuperSet of Anonymous FTP!!!
When you start a conversation comparing Gopher to FTP, this is "right
thought". Now the conversation takes on a different tone, and the whole
thought process changes. Without the WWW baggage, the mind leaps to new
concepts about ways to do things. Now thoughts of logical file structure,
speed, universality, and subject threads, suddenly spring into mind.
The first paragraph says it all: "It (RFC 1436) does not specify an Internet
This is a very important statement. From a historical standpoint, it confirms
that Gopher was developed independently, away from the mainstream "Internet"
development team (CERN being the 800-pound gorilla). It also, unfortunately
(or fortunately, depending on your perspective), means that the Gopher
standards have yet to be written in stone.
At first, everyone looked to the guys at UMN to provide direction. However,
with UMN washing their hands of Gopher in 2001 (Gopher Software made public
domain, the "Mother Gopher" having its plug-pulled, and the BoomBox FTP servers
files becoming corrupted), there is NO Official Source (like W3C) to turn to in
regards to Gopher "best practices".
At this time, it looks as if participants to this NewsGroup, and the operators
of the Super Gopher Servers, are the ones to whom the mantle of determining
"best practices" fall.
New portable platforms (such as cellphones, etc.) are limited to a more
streamlined approach in regards to Internet data capturing and display. Rural
communities are limited to Dial-up or slow Satellite links. Older platforms
are limited to file display capabilities (will someone PLEASE!!! make an
up-to-date PDF file viewer for DOS!?!). Gopher is an ideal protocol for
delivering content to these end users.
However... as there are no fixed Gopher standards (Gopher+ doesn't even rate an
RFC), we must be very careful about how we build future software, particularly
Servers, so that we do NOT leave older Clients behind. Just as importantly, we
must also configure our existing servers so that Clients from ALL platforms
(not just Unix-based ones) can take full advantage of the data presented (just
a your Web site should work with Lynx and WebTV).
For example: While most Unix-based platforms do not use "dot-plus-three" file
content description extensions; Tandy, DOS, and Windows platforms DO. Would it
be such an intolerable burden to include file extensions when you post a file
on Gopher, even if you and your friends may not use them? It sure would be
helpful to others if you did.
The beauty of the Internet is that you can transmit data on any port you like
(in fact, there are actually TOO MANY ports to choose from). For example,
while most persons choose to use Port 80 to transmit the HTTP protocol (because
most Web pages are for public consumption, and IANA has reserved Port 80 for
public consumption HTTP), you could transmit the data on some other port of
The same goes for Gopher. There are legitimate reasons why one might not want
to transmit on a commonly used port (such as for server testing). However,
IANA has reserved Port 70 for exclusive use by the Gopher protocol, for
transmitting public consumption Gopher. Why not use Port 70 for your server,
even if you could do otherwise? Some reasons include:
* For nearly all Server operators, using Port 70 is NOT an intolerable burden.
* Port 70 has been reserved by IANA for your use, so there are no "conflict"
* Many Routers are pre-configured OPEN on Ports 21, 70, and 80 (but block other
* Many Clients (and Servers) have been improperly "hard wired" to look only to
Port 70. Not using Port 70 would therefore prevent a large contingent of users
from accessing the information on your Server.
Item Types are a unique feature of Gopher. Other than with "file extensions",
FTP did not contain a way to designate the format of a file. FTP also did not
"link", so there was now also a need to tell the Client how to process a link.
Today, the Web Browsers have incorporated the email system of "Multipurpose
Internet Mail Extensions" (MIME). http://www.mhonarc.org/~ehood/MIME/
Gopher did it through a system called "Item Types". ALL Clients and Servers
support Item Types of "0" [plain text file], "1" [directory listing], and "9"
[binary file]. I strongly urge that all future Clients and Servers continue to
support Item Types 0, 1, and 9.
Note: For a long time, the JumpJet Server served any file that contained human
readable body text when printed on a TeleType machine (regardless if it
included advanced presentation "garbage" mixed in with the text) as Type 0. I
now see that this is not quite in the spirit of Type 0, and have modified the
Server to only serve TRUE "plain text" content (such as *.txt files) as Type
Item Type "3" [error message] was stillborn. Many Clients and Servers do not
Item Type "i" [informational message] is a late comer to the game; thrown in as
a perceived need, that was not considered in the original implementation of
Gopher. The output of Type "i" is unique to Gopher, and is not consistently
implemented. Too often Type "i" is used as a crutch, to supplement an unclear
file title, or to substitute for an "About.txt" file. Properly implemented
however, it can be an extremely useful Gopher enhancement. I, with reserve,
recommend Type "i" support in future Clients, Servers, and multi-protocol
Gopher and HTTP are not the only public protocols used on the Internet
Item Types "2" [CSO search query], "7" [search engine query], and "8" [telnet
session pointer] were reserved for three of these protocols. Type 2 and Type 8
were included only for the convenience of UMN students (so they wouldn't have
to use another Client just to access popular UMN resources). As such, Type 2
and Type 8, although still remaining reserved Item Types, could be dropped and
not incorporated. Type "7" is an important service (think "Veronica"), and
SHOULD be incorporated into future Clients and Servers.
An attempt has been make to break-out common file categories (sound files,
graphics files, binary archive files, etc.) from the Item Type 9 category, by
incorporating new Item Type designators (Type "s", Type "g", Type "5", etc.).
BEWARE. Not all Clients and Servers support these Item Types, even if they
appear in RFC 1436. Nor has the question been settled as to whether they
should even BE included (the use of "extensions", for example, can in most
instances serve the same purpose as using one of these singular Item Types)!
Problem: There has been talk of breaking down all files into their most basic
components. A document file, which might include both a photo and text, should
be broken into a Type "0" *.txt text file, and a Type "g" *.gif photo file.
While this is commendable, what do you do about *.pdf files? Many of these can
NOT be broken into separate segments (or even converted into picture files).
Should Type "d" [PDF file] be incorporated into future Clients and Servers? In
the interim, should most non-PDF files indeed BE broken apart?
Another problem: If new (or even existing) file defining Item Types (such as
"4", "5", "6", "d", "g", "h", "I", and "s") DO get the nod for inclusion, they
must WAIT until Server software can support them (remember, Gopher is a Smart
Server, Dumb Client, model). For example; there is only ONE choice for a
native "services" Gopher Server for Windows... GopherS. Until a replacement
becomes available, the ONLY Item Types that can be served from a Windows
platform are (besides hierarchy file management Types "1" and "i"), Types "0",
"4", "5", "6", "7", "9", "s", "I", "g", and "h".
TALK IS CHEAP:
If I encounter one more link to the "Gopher Manifesto", I think I will commit
Seppuku. Even this NewsGroup goes on and on with great ideas (as it should,
that is indeed productive, and it is one of the reasons this NewsGroup exists);
but NOTHING is being done through channels that are already in place.
For example: Links are external in Gopher. A recent discussion on this
NewsGroup debated using only focused (genus-like) links (only linking to
information directly relating to the subject, regardless of where in the
Internet it is located), vs. using "up options" to create broader (family-like)
links (also including links to information of a more global relationship to the
subject, so the end-user would not have to manually type a URL to move to a
shallower level on a linked Server).
What seems to have been overlooked is that there are ALREADY links to the more
broad-based information stockpiles. They are listed in "Gopher Jewels 2".
However NO ONE has sent a single link to be included in Gopher Jewels 2 (even
though contact information is included and link suggestions are actively
solicited). Come on people... send links to these repositories. This way, if
you wanted to link "broader", you could just include the appropriate GJ2 URL!
Another example: There have been endless debates about Ports and Item Types and
Presentation appearance, and File handling. Yet no one seems to have looked to
see what is actually being supported by the existing Gopher Clients and
Servers. Come on people... there are only a handful of Clients and Servers,
almost all being archived on JumpJet
Grab some, load them on your computer, do a few quick tests, and write a
paragraph or two review about them. I will post these reviews on JumpJet, so
this way everyone will actually KNOW what is or is not supported!!!
- [gopher] A Sunday morning diatribe,
JumpJet Mailbox <=