[gopher] A Sunday morning diatribe
Please allow me to indulge in a bit of Sunday morning musing and pontificating. Thanks.
MINDSET:
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:
http://www.dejavu.org/1992win.htm
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.
RFC 1436:
The first paragraph says it all: "It (RFC 1436) does not specify an Internet standard."
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.
COMPATABILITY:
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.
PORTS:
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 your choosing.
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" considerations.
* Many Routers are pre-configured OPEN on Ports 21, 70, and 80 (but block other Ports).
* 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:
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 0.
Item Type "3" [error message] was stillborn. Many Clients and Servers do not recognize it.
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 Browsers.
Gopher and HTTP are not the only public protocols used on the Internet network. See
http://home.jumpjet.info/Gopher/access.htm
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
gopher://home.jumpjet.info/11\Begin_Here
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!!!
Reply to: