Copy Link
Add to Bookmark
Report
Public-Access Computer Systems Review Volume 04 Number 02
+ Page 1 +
-----------------------------------------------------------------
The Public-Access Computer Systems Review
Volume 4, Number 2 (1993) ISSN 1048-6542
-----------------------------------------------------------------
To retrieve an article file as an e-mail message, send the GET
command given after the article information to LISTSERV@UHUPVM1
(BITNET) or LISTSERV@UHUPVM1.UH.EDU (Internet). To retrieve the
article as a file, omit "F=MAIL" from the end of the GET command.
CONTENTS
COMMUNICATIONS
The University of Minnesota's Internet Gopher System: A Tool for
Accessing Network-Based Electronic Information
By Rich Wiggins (pp. 4-60)
To retrieve this file: GET WIGGINS1 PRV4N2 F=MAIL
GET WIGGINS2 PRV4N2 F=MAIL
This article describes the Internet Gopher: why it is needed, how
it is used, its genesis and early evolution, the underlying
protocol (and the new Gopher+ protocol), Gopher's role as a
campus-wide information system (CWIS), and its emerging role as
an Internet-wide information system. The article also discusses
navigational enhancements (e.g., Veronica), organization and
quality of service issues, privacy and security concerns,
electronic publishing issues, distribution of multimedia
information, related client and network information technologies,
and Gopher's future.
COLUMNS
Casting the Net
Cataloging Internet Resources
By Priscilla Caplan (pp. 61-66)
To retrieve this file: GET CAPLAN PRV4N2 F=MAIL
+ Page 2 +
-----------------------------------------------------------------
The Public-Access Computer Systems Review
-----------------------------------------------------------------
Editor-in-Chief
Charles W. Bailey, Jr.
University Libraries
University of Houston
Houston, TX 77204-2091
(713) 743-9804
LIB3@UHUPVM1 (BITNET) or LIB3@UHUPVM1.UH.EDU (Internet)
Associate Editors
Columns: Leslie Pearse, OCLC
Communications: Dana Rooks, University of Houston
Reviews: Roy Tennant, University of California, Berkeley
Editorial Board
Ralph Alberico, University of Texas, Austin
George H. Brett II, Clearinghouse for Networked Information
Discovery and Retrieval
Steve Cisler, Apple Computer, Inc.
Walt Crawford, Research Libraries Group
Lorcan Dempsey, University of Bath
Nancy Evans, Pennsylvania State University, Ogontz
Charles Hildreth, University of Washington
Ronald Larsen, University of Maryland
Clifford Lynch, Division of Library Automation,
University of California
David R. McDonald, Tufts University
R. Bruce Miller, University of California, San Diego
Paul Evan Peters, Coalition for Networked Information
Mike Ridley, University of Waterloo
Peggy Seiden, Skidmore College
Peter Stone, University of Sussex
John E. Ulmschneider, North Carolina State University
Technical Support
Tahereh Jafari, University of Houston
+ Page 3 +
Publication Information
Published on an irregular basis by the University Libraries,
University of Houston. Technical support is provided by the
Information Technology Division, University of Houston.
Circulation: 6,403 subscribers in 56 countries (PACS-L) and 1,428
subscribers in 42 countries (PACS-P).
Back issues are available from LISTSERV@UHUPVM1 (BITNET) or
LISTSERV@UHUPVM1.UH.EDU (Internet). To obtain a list of all
available files, send the following e-mail message to the
LISTSERV: INDEX PACS-L F=MAIL. The name of each issue's table of
contents file begins with the word "CONTENTS."
The first two volumes of The Public-Access Computer Systems
Review are also available in book form from the American Library
Association's Library and Information Technology Association
(LITA). The price of each volume is $17 for LITA members and $20
for non-LITA members. To order, contact: ALA Publishing
Services, Order Department, 50 East Huron Street, Chicago, IL
60611-2729, (800) 545-2433.
-----------------------------------------------------------------
The Public-Access Computer Systems Review is an electronic
journal that is distributed on BITNET, Internet, and other
computer networks. There is no subscription fee.
To subscribe, send an e-mail message to LISTSERV@UHUPVM1
(BITNET) or LISTSERV@UHUPVM1.UH.EDU (Internet) that says:
SUBSCRIBE PACS-P First Name Last Name. PACS-P subscribers also
receive two electronic newsletters: Current Cites and Public-
Access Computer Systems News.
The Public-Access Computer Systems Review is Copyright (C)
1993 by the University Libraries, University of Houston. All
Rights Reserved.
Copying is permitted for noncommercial use by academic
computer centers, computer conferences, individual scholars, and
libraries. Libraries are authorized to add the journal to their
collection, in electronic or printed form, at no charge. This
message must appear on all copied material. All commercial use
requires permission.
-----------------------------------------------------------------
+ Page 61 +
-----------------------------------------------------------------
Casting the Net
-----------------------------------------------------------------
-----------------------------------------------------------------
Caplan, Priscilla. "Cataloging Internet Resources." The Public-
Access Computer Systems Review 4, no. 2 (1993): 61-66. To
retrieve this file, send the following e-mail message to
LISTSERV@UHUPVM1 or LISTSERV@UHUPVM1.UH.EDU: GET CAPLAN PRV4N2
F=MAIL.
-----------------------------------------------------------------
Let Archie Do It?
How do we accommodate networked electronic information when our
cataloging rules are designed to describe physical items owned by
and residing in libraries? How do we provide access to that
information? Do we let Archie do it instead? Questions like
these must be addressed before we can move into the future and
provide our patrons with information the way they are coming to
expect it. It isn't sufficient that we simply debate these
issues at conferences and write about them in the literature.
Action is needed, and well-established rules and practices must
be changed. All of that is easy to agree with, but deciding how
to change established rules and practices is another matter, not
to mention actually revising them.
What Are Online Information Resources?
MARBI is an ALA committee that advises the Library of Congress on
additions and changes to the USMARC formats. Usually, MARBI
deals with issues like where to record the International Standard
Music Number and whether to add new coded values for Betacam
videocassettes to the Physical Description Fixed Field. Last
winter, however, a new proposal generated quite a bit of
attention. Proposal 93-4 recommended changes to the
bibliographic format to accommodate electronic data resources
such as e-journals and documents available over the Internet.
+ Page 62 +
Proposal 93-4 can trace its roots back to the summer of 1991
when MARBI Discussion Paper 49 proposed a set of data elements
that might be useful in describing online information resources.
Discussion of that paper, however, revealed some uncertainty
about exactly what was being described. Was "online-ness" the
salient quality, and if so, what did it mean to be online? Was
it network accessibility? The property of being in electronic
form?
Over the next year, some progress was made in sorting these
things out. It became clear, for example, that remote access was
the defining and unifying quality of these materials--the fact
that they could not be held in the hand, physically described,
pointed to on a shelf, or checked out to patrons. It was also
agreed that for the sake of simplicity the universe of remotely
accessed entities could be divided into two categories: (1) data
resources (e.g., software, text and data files, and bibliographic
databases) and (2) systems or services (e.g., campus-wide
information systems, library catalog systems, and bulletin
boards). A rough but intuitive analog might be those things that
one could FTP and those to which one could Telnet. Since
electronic data resources more closely resemble what libraries
are accustomed to cataloging than online systems do, MARBI
decided in the winter of 1992 to concentrate on these first.
Joint Cataloging Project
Meanwhile, OCLC's Office of Research had received a grant from
the Department of Education to investigate the nature of
electronic information available over the Internet. OCLC's
project staff had already collected and categorized more than
1,500 files. In the spring of 1992, representatives from the
OCLC Internet Resources Project, MARBI, the Library of Congress,
and the Online Audiovisual Catalogers teamed up for an experiment
in cataloging electronic data resources. The group started with
the hope that the existing USMARC computer files format could be
used for remote data resources without too many modifications.
This may sound simple, but for historical reasons the computer
files format is surprisingly limited in its ability to describe
computer files. It was originally designed with only a single
type of file in mind--statistical data sets like Harris survey
responses or the census. Later it was expanded to handle the
microcomputer software that libraries had begun to collect. As
such, it's like a house with only two rooms: a kitchen and a
bedroom. OK until you want to take a bath.
+ Page 63 +
Anyway, the project group took a sample of 300 data
resources (mostly documents), drafted some preliminary cataloging
guidelines, and sent the samples and guidelines to 30 volunteer
catalogers so that each resource would be cataloged independently
by three different catalogers. The volunteers were instructed to
use the USMARC computer files format and AACR2 cataloging rules
as best they could, and to keep a log of their particular
problems, questions, and suggestions. The results were then
compared, analyzed, and used to indicate where people were
confused and where the format or the rules were deficient. The
end products were a revised, more extensive set of cataloging
guidelines and some recommended changes to the computer files
format in the form of MARBI Proposal 93-4.
Recommended Changes
The recommended changes to the format for descriptive purposes
were not extensive, but they required a modification to the
cataloging rules. An existing MARC field called "File
Characteristics" (256) is governed by AACR2 Chapter 9, which
specifies that one of three terms must be used: "computer data,"
"computer program(s)," or "computer data and program(s)"
(kitchen, bedroom, kitchen and bedroom). Proposal 93-4
recommended extending the set of allowable terms to include such
descriptors as "electronic document," "electronic journal,"
"bibliographic database," "graphic," and "computer sounds." (A
parallel set of coded values was defined in a fixed field data
element to allow retrieval or reporting by these same concepts.)
The rationale was simply to give brief, clear, descriptive
information to the library patron, who might not intuitively
think of an e-journal, for example, as "computer data."
Alas, expansion of the "File Characteristics" field was not
approved by MARBI, on the grounds that the cataloging change must
precede the format change. The issue was referred to CC:DA,
another ALA committee that stands in very roughly the same
relation to the cataloging rules as MARBI does to the USMARC
format. As far as I know, CC:DA has not yet pronounced on this
issue. Meanwhile, "computer data" it is.
+ Page 64 +
The biggest change proposed in Proposal 93-4 was not for the
purpose of description but rather of location. In effect, it was
decided that FTP sites, list servers, and the like constituted
electronic locations that conceptually parallel physical ones.
The paper form of a document might be on a shelf in a library,
while a bitmapped form might be available from a file server on
the Internet. A new field was invented for "Electronic Location
and Access" (856), including data elements for type of access
(e.g., e-mail, FTP, and Telnet), host name, path name, file name,
and similar information necessary to access or retrieve a data
resource over the network. Although much more radical an idea
than the expanded list of file characteristics, this
recommendation was independent of cataloging rules and so passed
in slightly modified form at the January 1993 MARBI meeting. The
"Electronic Location and Access" field is now formally part of
the USMARC format.
Points to Ponder
At this point, it might be a good idea to pause and ask ourselves
some questions. First, does it make sense for libraries to be
cataloging Internet materials to begin with? Even if it does, is
MARC the way to go about it? In fact, a vast number of data
resources are available via the Internet, most of them
uncontrolled, unverified, and of limited or ephemeral interest.
(PACS-L readers may be reminded of the recent flap over an
incomplete version of the Periodic Table.) Libraries are likely
to have interest in only a small subset of this universe. For
this subset, however, network access may actually be used to
replace or supplement library ownership and physical access.
Certainly, libraries will want these materials fully described.
Similarly, such description or cataloging should be available in
the same online catalog systems as the rest of the libraries'
holdings, which implies that the records should be in the same
format and follow the same rules as other bibliographic data.
+ Page 65 +
Won't network tools like Archie and Gopher supersede library
catalogs for electronic data resources? These are wonderful
tools, but they do have limitations we wouldn't tolerate for more
traditional library materials. To quote another MARBI discussion
paper (No. 69, April 30, 1993):
Many do not give you any indication of which servers they
actually searched and which were unavailable for one reason
or another. They do not discriminate between various
versions of data in terms of usefulness or completeness.
They are poor at locating known items, as opposed to
possibly relevant things. In addition, the subject analysis
available in USMARC records is lacking in these other tools.
. . . Such tools could complement rather than replace USMARC
records as a source for locating online objects.
But electronic addresses change often as documents move from
server to server and from format to format. Does it make sense
to actually imbed location information in the descriptive record
itself? Well, probably not. In fact, the Internet Engineering
Task Force is working on a much more efficient scheme. A
Universal Resource Identifier (URI)--much like the ISBN--would be
assigned to each object by the originating agency. A Universal
Resource Locator (URL), similar in concept to the Electronic
Location and Access field, would identify a location. Only URIs
would be imbedded in the bibliographic description, and computers
would associate the URI with one or more URLs in much the same
way an Internet host name (HARVARDA.HARVARD.EDU) is associated
with its IP address (128.103.60.11) by the name server system.
However, someone needs to do all this; an infrastructure needs to
be developed and responsible agencies in agreement on
responsibilities and procedures. Once this mechanism is in
place, we can decide what to do next with the Electronic Location
and Access field. Meanwhile, it allows us to begin building
records and testing the feasibility of catalog access to
electronic data resources.
Finally, can we really separate data resources from
systems/services? Is there a distinction between a database and
the retrieval system required to access it? Probably not.
Although a useful distinction to get the project going, the line
between these concepts was fuzzy to begin with and gets fuzzier
the more you think about it.
+ Page 66 +
Next Steps
The next step is clearly to try to accommodate online systems and
services in USMARC as well. Some of the relevant data elements
such as hours of service and cost for use don't currently exist
in the bibliographic formats, but they are defined in the new
USMARC Community Information Format. We may end up with a hybrid
that seems "bibliographic" in some respects and like a program or
agency in others. Discussion Paper no. 69, "Accommodating Online
Systems and Services in USMARC," addresses these issues. It
will come up for discussion when MARBI meets at the ALA annual
conference in New Orleans. You can request the paper by sending
this e-mail message: GET DP69 DOC to LISTSERV@MAINE.MAINE.EDU.
Or, as the Electronic Location and Access field would have it:
856 0 $a maine.maine.edu $f dp69 doc $h listserv $i get
About the Author
Priscilla Caplan, Head, Analysis and Programming Division, Office
for Information Systems, Harvard University Library. Internet:
COTTON@HARVARDA.HARVARD.EDU.
-----------------------------------------------------------------
The Public-Access Computer Systems Review is an electronic
journal that is distributed on BITNET, Internet, and other
computer networks. There is no subscription fee.
To subscribe, send an e-mail message to LISTSERV@UHUPVM1
(BITNET) or LISTSERV@UHUPVM1.UH.EDU (Internet) that says:
SUBSCRIBE PACS-P First Name Last Name. PACS-P subscribers also
receive two electronic newsletters: Current Cites and Public-
Access Computer Systems News.
This article is Copyright (C) 1993 by Priscilla Caplan. All
Rights Reserved.
The Public-Access Computer Systems Review is Copyright (C)
1993 by the University Libraries, University of Houston. All
Rights Reserved.
Copying is permitted for noncommercial use by academic
computer centers, computer conferences, individual scholars, and
libraries. Libraries are authorized to add the journal to their
collection, in electronic or printed form, at no charge. This
message must appear on all copied material. All commercial use
requires permission.
-----------------------------------------------------------------
+ Page 4 +
-----------------------------------------------------------------
Wiggins, Rich. "The University of Minnesota's Internet Gopher
System: A Tool for Accessing Network-Based Electronic
Information." The Public-Access Computer Systems Review 4, no. 2
(1993): 4-60. To retrieve this file, send the following e-mail
messages to LISTSERV@UHUPVM1 or LISTSERV@UHUPVM1.UH.EDU: GET
WIGGINS1 PRV4N2 F=MAIL and GET WIGGINS2 PRV4N2 F=MAIL.
-----------------------------------------------------------------
1.0 Introduction
Late in 1991, a new creature began burrowing its way around the
Internet. This new critter helps people browse many of the
resources available on local campus networks or on the worldwide
Internet. Called the Internet Gopher, this tool was developed at
the University of Minnesota. Pioneering sites began deploying
Gopher servers in December 1991. In the short time since, the
Gopher system (henceforth called "Gopher") has been deployed at
many institutions around the world. A worldwide community of
"Gophernauts" has come into being, with various sites
contributing ideas, utility tools, bits of code, and schemes for
cooperative registry efforts. Gopher now accounts for a
substantial fraction of the traffic on the Internet. Gopher
servers are delivering text, index searches, still images, audio,
public domain software, and more to users all over the world.
With Gopher, a user can:
o Find out what movies are playing in Aachen, Germany.
o Learn what earthquakes took place yesterday.
o Read today's student newspaper from a school 2,000
miles away.
o Pick up a quote from Paradise Lost for a term paper.
o Read the city council meeting minutes from Wellington,
New Zealand.
o Listen to the final U.S. Presidential Debate of 1992.
o See what Michigan State's campus looks like in spring.
o Read about the Human Genome Project.
o Learn about Federal grants.
o Download public domain software.
+ Page 5 +
The above examples are a tiny sample of the kinds of information
Gopher can deliver. An illustration of the value of Gopher comes
from a user who works at Michigan State University:
I wanted to drop a quick line and tell you how much Gopher
means to me. I discovered Gopher about two months ago and
cannot believe how much information is out there. I have
found the new Veronica option very helpful as it allows me
to build a directory of items that are specific to my
interest. This is undoubtedly a great service for anyone
who finds it. However, for me it is unbelievable. I am
legally blind and I have always said that the most difficult
aspect of blindness is the lack of readily available
information. Gopher has the ability to change all of that.
For the first time, I feel like I can easily and
independently access important campus and worldwide
information. . . . I use a speech synthesizer and a PC
compatible computer to access the Gopher system.
This article describes the Internet Gopher: why it is needed, how
it is used, its genesis and early evolution, the underlying
protocol (and the new Gopher+ protocol), Gopher's role as a
campus-wide information system (CWIS), and its emerging role as
an Internet-wide information system. The article also discusses
navigational enhancements (e.g., Veronica), organization and
quality of service issues, privacy and security concerns,
electronic publishing issues, distribution of multimedia
information, related client and network information technologies,
and Gopher's future.
2.0 The Internet and the Need for Navigation Tools
Today, many computer users at universities, government agencies,
and commercial firms are connected in one way or another to the
Internet. The Internet is a worldwide network of networks.
Campus Ethernets and other local area networks are connected
together by a complex web under the aegis of regional networks,
national networks, or in some countries, the PTTs
(postal/telephone authorities). The constituent networks all use
the TCP/IP protocol family; the result is a worldwide network of
computers that can communicate with one another. The Internet
evolved from the old Defense Advanced Research Projects Agency
network (ARPANET). ARPANET sites consisted mainly of Department
of Defense research installations and affiliated research
institutes and universities. Many thousands of host computers
and user workstations now have Internet connectivity. The number
of computer users with Internet access is estimated to exceed 10
million.
+ Page 6 +
As a "network of networks," the Internet can be thought of
as the aggregation of various campus, corporate, and other
networks. Other than following certain rules known as
"acceptable use policies," institutions on the Internet are
generally autonomous. Therefore, services that are offered on
these campus networks are provided because some local service
provider believes it's worthwhile to do so. Often, the
motivation is to serve local users. For example, a campus
library puts its online catalog on the campus network for the
sake of local patrons, not primarily for the benefit of Internet
users.
As multiple campuses mounted similar services to satisfy the
needs of their own communities, Internet users began to find
value in using online resources from other institutions. For
instance it might be useful to scan the online catalog of a
partner interlibrary loan institution. But without a list of
host names (or IP addresses) of the various online catalogs on
the Internet, each individual user has to maintain his or her own
listing: picture a wall of Post-it notes listing names and
addresses next to a user's PC.
Online catalogs aren't the only list of Internet services a
user would want to keep up with; all sorts of services are
available on the Internet. Examples include:
o List servers and discussion groups.
o USENET News (a sort of distributed discussion
facility).
o Anonymous FTP archives, containing public domain
software and other offerings.
o Tools and services for finding people.
o Host computers that require assigned passwords.
o Databases that allow logins via Telnet.
o Databases that support the client/server model (the
chief example is WAIS).
o Archives of electronic journals and books--the nascent
virtual library.
+ Page 7 +
The need for an "Internet address book" applies to all of these
kinds of services. Several tools are evolving to help bring
order to the Internet. Various Internet navigation tools have
different goals and capabilities:
o HYTELNET provides a hypertext database of online
catalogs and other systems.
o Archie serves as an index of FTP sites, identifying
sites that hold particular files.
o WAIS allows users to search one or more databases using
natural language queries; it presents ranked search
results.
o World-Wide Web supports networked hypertext.
All of these tools will be discussed later in this paper. For
now, the focus is Gopher.
In a nutshell, Gopher offers access to files and interactive
systems using a hierarchical menu system. The organization of
the menu is defined by the administrator of each server. The
resources that each menu item describes, such as ASCII files,
Telnet sessions to other computers, and submenus, are called
"documents." The scope of a Gopher server could be limited to a
campus or to a subject area. Or, a Gopher server could include a
catalog of a variety of Internet resources. The following
section depicts a "walk-through" of "Gopherspace," showing how
Gopher operates along the way.
3.0 Overview of Gopher from the User's Point of View
Gopher serves as a menu system for networked information. The
user connects to one of the thousands of Gopher servers now in
production around the world and receives an initial (or "root")
menu. When you use a tool like Archie, you are asking the server
a specific question (e.g., "Tell me what FTP sites can provide a
copy of the program named PKZIP"). When you connect to a Gopher
server, you are asking it "Give me a menu listing the resources
you have to offer." The menu can include submenus. Each Gopher
server presents a hierarchy established by the local
administrator.
+ Page 8 +
Gopher follows the client/server model. This model divides
the labor between the program the user invokes (the "client") and
a program running on a host computer, such as a UNIX workstation
or a mainframe (the "server").
It's best to run Gopher with client software installed on
the user's workstation because it provides a superior user
interface and opens up the world of still images, audio files,
and other resources. But a user who has not installed a client
can still use Gopher: the developers have provided a sort of
central client software, and many Gopher sites offer public
client services. The public client software is sometimes known
as the "curses" client, after the UNIX screen management tool of
that name. Users connect to these public client services via
Telnet (or, depending on their local network services, via a VT
100 dial-up session).
The following initial tour of Gopherspace will use sample
screens from a public client service. This example will connect
to the service offered at the home of Gopher, the University of
Minnesota. To connect to the public client service at "Gopher
Central," one would type the following:
telnet consultant.micro.umn.edu
gopher [Type "gopher" in response to login prompt.]
The user's Telnet program must be capable of VT 100-style full-
screen operations (virtually all are). The client service will
respond as shown in Figure 1.
-----------------------------------------------------------------
Figure 1. Choosing the Terminal Type
-----------------------------------------------------------------
TERM = (vt100) [Press Enter at this prompt.]
Erase is Ctrl-H
Kill is Ctrl-U
Interrupt is Ctrl-C
I think you're on a vt100 terminal
-----------------------------------------------------------------
At this point, the user should hit the Enter key. Having made
this connection, the user would see the root menu of the
University of Minnesota's Gopher service (see Figure 2).
+ Page 9 +
-----------------------------------------------------------------
Figure 2. The University of Minnesota Gopher's Root Menu
-----------------------------------------------------------------
Internet Gopher Information Client v1.12
Root gopher server: gopher.tc.umn.edu
--> 1. Information About Gopher/
2. Computer Information/
3. Internet file server (ftp) sites/
4. Fun & Games/
5. Libraries/
6. Mailing Lists/
7. UofM Campus Information/
8. News/
9. Other Gopher and Information Servers/
10. Phone Books/
11. Search lots of places at the U of M <?>
Press ? for Help, q to Quit, u to go up a menu Page:1/1
-----------------------------------------------------------------
As noted above, Gopher presents a hierarchical menu; titles
ending in a slash ("/") are submenus (or "subdirectories" or
"folders") that list additional choices. For example, if the
user presses Enter while the cursor points at the first menu
item, a submenu of resources about Gopher will appear. The user
can choose among the menu items by using the cursor keys or by
typing in the number of the desired menu item. If the menu is
longer than will fit on one screen, the "Page: n/m" field in the
lower right corner so indicates.
After selecting the "Information About Gopher" menu item,
Gopher responds with the menu shown in Figure 3.
+ Page 10 +
-----------------------------------------------------------------
Figure 3. Information About Gopher Menu
-----------------------------------------------------------------
Internet Gopher Information Client v1.12
Information About Gopher
--> 1. About Gopher.
2. Search Gopher News <?>
3. Gopher News Archive/
4. comp.infosystems.gopher (USENET newsgroup)/
5. Gopher Software Distribution/
6. Gopher Protocol Information/
7. Frequently Asked Questions about Gopher.
8. Gopher+ example server/
9. How to get your information into Gopher.
10. New Stuff in Gopher.
11. Reporting Problems or Feedback.
12. big Ann Arbor gopher conference picture.gif <Picture>
13. gopher93/
Press ? for Help, q to Quit, u to go up a menu Page:1/1
-----------------------------------------------------------------
This menu in the University of Minnesota Gopher server is the
definitive place to learn about Gopher. Note that menu items for
ASCII text files are listed with a period at the end.
Upon selecting the first menu item ("About Gopher"), the
file shown in Figure 4 would appear.
+ Page 11 +
-----------------------------------------------------------------
Figure 4. About Gopher File
-----------------------------------------------------------------
This is the University of Minnesota Computer & Information
Services Gopher Consultant service.
gopher n. 1. Any of various short tailed, burrowing mammals of
the family Geomyidae, of North America. 2. (Amer. colloq.)
Native or inhabitant of Minnesota: the Gopher State. 3. (Amer.
colloq.) One who runs errands, does odd-jobs, fetches or
delivers documents for office staff. 4. (computer tech.)
Software following a simple protocol for tunneling through a
TCP/IP internet.
If you have questions or comments, you can get in contact with
the Gopher development team by sending e-mail to:
gopher@boombox.micro.umn.edu
If you are interested in news about new gopher servers and
software you can subscribe to the gopher-news mailing list by
sending e-mail to:
gopher-news-request@boombox.micro.umn.edu
There is also a USENET news discussion group called
comp.infosystems.gopher
where Internet Gopher is discussed.
If you want to get the most recent releases of the gopher
software, you can get these via anonymous ftp from
boombox.micro.umn.edu in the /pub/gopher directory.
Press <RETURN> to continue, <m> to mail:
-----------------------------------------------------------------
In the above example, the curses client leaves the text of the
selected text file on the screen until the user types Enter.
After that, the "Information About Gopher" menu will be
redisplayed. Because Gopher is organized hierarchically, you
need a way to move back a level in the directory tree. With the
public "curses" client the user simply types "u" for "up." No
matter how deep in the hierarchy the user travels, the client is
able to back up, one menu at a time, until the root menu is
redisplayed.
+ Page 12 +
The "Information About Gopher" menu above included a menu
item entitled "2. Search Gopher News <?>"; this menu item offers
an index search, as denoted by the question mark. Gopher servers
generally implement indexing using the public domain WAIS (Wide
Area Information Servers) search engine. (A common exception:
servers implemented on NeXT workstations often exploit the
Digital Librarian delivered with NeXTStep.) Upon selecting this
menu item, the user is prompted to enter a keyword (see Figure
5).
-----------------------------------------------------------------
Figure 5. Search Gopher News
-----------------------------------------------------------------
+-------------------Search Gopher News--------------------+
| |
| Words to search for: indiana |
| |
| [Cancel ^G] [Accept - Enter] |
| |
+---------------------------------------------------------+
-----------------------------------------------------------------
Note that most Gopher clients will highlight the sought keyword
within the text of the displayed document. This makes it easy to
find the occurrences of the keyword in context.
Searching is not currently as flexible as one would like.
In particular, the standard release with the WAIS engine does not
provide for Boolean or proximity searches. In November 1992, Don
Gilbert of Indiana University announced modifications to the WAIS
indexing engine normally used with Gopher servers. His
enhancements include Boolean, partial word search, and literal
phrase searching. His biology-oriented Gopher (located at
ftp.bio.indiana.edu, port 70) allows testing of these search
features. Examples of the kinds of searches possible include:
o Boolean: red and green not blue. Result: just those
records with both the words "red" and "green,"
excluding all records with the word "blue."
o Partial words: hum*. Result: all records with "hum"
(e.g., "hummingbird," "human," and "humbug").
+ Page 13 +
o Literal phrases: red rooster-39. Result: only those
records with the full string "red rooster-39" will be
retrieved.
The scope of a Gopher index is determined by the administrator.
The administrator can choose to index one file, all files in a
subdirectory, or all files in a directory and its subdirectories.
Often a large file is broken up into a series of small files so
that it can be loaded into Gopher. This will allow the user to
selectively retrieve sections of interest. Usually, the wording
of the Gopher menu item makes it clear what the scope of a given
index is. It's the administrator's job to make sure this is the
case.
You can best learn more about Gopher by browsing through
various servers: connect to "Gopher Central" (gopher.tc.umn.edu,
port 70) and follow the list of Gophers. Alternatively, you
might use the global title index at Michigan State's central
Gopher to look up these Gopher servers (or any others of
interest) by keyword. (The index of Gopher server names is on
gopher.msu.edu, port 70; look under the "More About Gopher/Other
Gopher Servers" menu item.) Also, you may want to try Veronica
(discussed below) as a way to locate specific Gopher documents.
4.0 Gopher Clients
Recall that the above examples came from using the public client.
The best access to Gopher documents requires use of Gopher client
software running on the user's workstation. Gopher clients have
been implemented on a variety of platforms. The University of
Minnesota keeps an archive of commonly used clients, developed
there or elsewhere, on its anonymous FTP service, which is
located on boombox.micro.umn.edu. Common clients include:
o PC Gopher III--the University of Minnesota's PC client,
which was written using Borland's TurboVision. It
provides a quasi-graphical interface complete with
mouse support. PC Gopher is a relatively large
program. Since memory use on networked PCs is tight,
the program's size has been problematic.
+ Page 14 +
o UGOPHER--a PC client from the University of Texas
Medical School at Houston. It is a port of the UNIX
curses client. It provides a very simple interface,
but it demands little memory. It supports special data
types such as TN3270 and still-image files.
o Novell LWP client--a PC client from the University of
Michigan Medical School. This client works with
Novell's LAN Work Place for DOS. It supports images
and audio as well as TN3270. It sports a friendly
graphical interface with more options than the standard
client. As of this writing, it does not support a
mouse.
o Gopher Book--a Windows client from the Clearinghouse
for Networked Information Discovery and Retrieval.
Gopher Book runs under Microsoft Windows and implements
a book-like view of Gopherspace. The Gopher community
has long wanted a good Windows client; this could be
it. (Users may want to FTP to sunsite.unc.edu and look
under pub/micro/pc-stuff/ms-windows/winsock for Gopher
Book and related tools, such as the Winsock DLL.)
o TurboGopher for the Macintosh--a Macintosh client from
the University of Minnesota. Various Mac Gophers have
been implemented, at the University of Utah, Brown
University, and at other sites. TurboGopher appears to
be highly functional, robust, and efficient, and it is
on its way to superseding the other Mac offerings.
o Curses client--a generic client for UNIX workstations.
It is also used at many Gopher sites to provide Telnet
access to the Gopher world for users who haven't yet
obtained client software for their workstations. Users
installing the curses client on their UNIX workstations
must build the client from source code on the target
machine (as is commonly true with UNIX software
offerings). A version of this client can also be
compiled for use under the DEC VMS operating system.
+ Page 15 +
o NeXT Gopher Client--a NeXT client from the University
of Minnesota and the University of St. Thomas. This
client makes good use of the NeXT's large windows, and
it leaves the last two or more menus on the screen,
providing useful contextual information. Recent
modifications have been implemented by Jim Lebay of
Michigan State (icon support, bug fixes, better
handling of windows, and support for image files) and
David Lacey of the University of Iowa (support for the
MIME protocol).
o Xgopher--a client from Allan Tuchman at the University
of Illinois that runs under X-based UNIX systems. (The
X release must be later than X11 Release 3.) Xgopher
supports multiple active items and an easy-to-use
graphical user interface. It is highly configurable.
A C compiler is needed to build the client for the
target user's machine.
o Rice University CMS Client--a client that allows users
of VM/CMS mainframes to connect to Gopher servers. The
host must have outbound VT 100 Telnet to function well
when connecting to Unix-based services. (The IBM 3270
terminal protocol does not lend itself well to outbound
connections to byte-oriented hosts; check with local
support personnel to determine if such access is
available at your site.)
o MVS Gopher Client--a client from Draper Laboratory for
TSO users on MVS mainframes. This client can provide
3270 terminals with access to Gopher services.
An experimental OS/2 client has been announced by David Singer of
IBM Almaden (look for os2gopher.zip on boombox.micro.umn.edu).
Gopher clients vary widely in their appearance and features.
The same documents may be displayed to users in quite different
form, depending on which client is used. Ultimately, the
information is the same, even though the display format varies.
(Marshall McLuhan would have a field day.) Some clients allow
the user to print an entire document. With the PC client, the
document goes to a locally attached printer; however, the NeXT
client assumes its printer is a PostScript device, which might be
connected over the local Ethernet. Some clients let the user
save a document to the local workstation's disk; others allow the
user to send a document via e-mail to the destination of choice.
+ Page 16 +
Gopher clients need a way to display files on the user's
screen. This can be done by code within the client program
itself. Alternatively, the client may launch an external tool,
often called a "browser" or a "pager." For instance, UGOPHER has
a relatively limited built-in browser. The user can install a
superior file display tool, such as the popular shareware tool
LIST from Vernon D. Buerg, and tell UGOPHER to use it instead.
Similarly, clients may launch separate programs to open
Telnet sessions, do CSO searches, play audio files, and so forth.
The user must install all the needed external tools and configure
the client to use them. Installation instructions are provided
with every client.
A useful feature in many clients is the "bookmark." Upon
finding an item of particular interest, the user sets a bookmark.
The client software stores the bookmark on the client
workstation's disk. In a later session, the user can call up the
list of bookmarks and immediately jump to items of particular
interest without having to navigate the menus. Because resources
of interest could be buried deep within Gopher servers, the
bookmark option lets the user build a customized view of
Gopherspace. (Some users have suggested the need for
hierarchical bookmarks; the current bookmarks provide a simple
flat list.)
Most clients also have the ability to save documents
themselves on the user workstation. Some information providers
have found that Gopher makes a very efficient mechanism for
delivering files to users. At least one software archive
encourages its users to obtain software via Gopher instead of
anonymous FTP. (The Stanford University Macintosh archive,
Sumex, suggests users choose Gopher over FTP or other methods.)
Gopher was originally written with the assumption that the
user would be resident on the Internet, with a permanently
assigned IP address, and have client software on his or her
workstation. This model does not always provide dial-up users
(users dialing in over a phone line using asynchronous ASCII
terminal emulators) with the same level of service as on-campus
users receive. Many institutions are experimenting with schemes
to allow dial-up users to appear to be on the Ethernet, using
protocols such as SLIP (Serial Line IP) and PPP (Point-to-Point
Protocol). Under SLIP or PPP, the user can run a standard Gopher
client, which works as if it were on a local TCP/IP network. (Of
course, data is delivered more slowly; even today's high-speed
modems don't match local area network speeds.) Because these
dynamic IP assignment schemes are relatively new and they are not
widely used, traditional dial-up users must usually rely on the
public curses client.
+ Page 17 +
In general, users who run Gopher clients benefit from a
superior environment and have access to more data types.
However, recent versions of the public curses client make it
possible for users to download files for viewing outside of their
terminal session. To download a file, one strikes a "D" (that's
a capital "D"; use lower "d" at your peril, for that says you
want to delete a bookmark) with the cursor on the document title.
When this option is invoked, the public client service asks the
user which protocol to use (i.e., raw text, Kermit, XMODEM,
YMODEM, or ZMODEM). Assuming the user's terminal emulator can
handle one of these protocols, this allows the dial-up user to
obtain a copy of a file, such as a still-image file, that
otherwise could not be displayed using the curses service.
5.0 Obtaining a Gopher Client Via FTP
A common way to obtain a client is by use of anonymous FTP. The
University of Minnesota's software archive resides on
boombox.micro.umn.edu. Other sites also maintain their own
archives, which may include local fixes or enhancements. In
particular, sites may configure clients to point to local Gopher
servers by default, or they may make changes to allow the clients
to work properly with the local network environment. New Gopher
users should consult with local computer support staff to
determine where best to obtain a client.
The following is an example of obtaining the University of
Minnesota's client for MS-DOS (see Figure 6). It assumes that
the user has a copy of PKZIP, a popular file compression
shareware tool.
+ Page 18 +
-----------------------------------------------------------------
Figure 6. Example FTP Session to Download a Gopher Client
-----------------------------------------------------------------
C:\GOPHER: ftp boombox.micro.umn.edu
Connected to boombox.micro.umn.edu.
Connected to boombox.micro.umn.edu.
220 boombox FTP server (Version 4.1 Tue Apr 10 05:15:32 PDT 1990)
ready.
Name (boombox.micro.umn.edu:rww): ftp
331 Guest login ok, send ident as password.
Password:wiggins.msu.edu
230 Guest login ok, access restrictions apply.
ftp> cd pub/gopher/PC_client
250 CWD command successful.
ftp> dir
200 PORT command successful.
150 Opening ASCII mode data connection for /bin/ls (0 bytes).
total 1352
-rw-r--r-- 1 bin 385 Apr 1 15:43 00readme
-rw-r--r-- 1 bin 0 Mar 22 17:29
FTP_THESE_FILES_IN_BINARY_MODE
-rw-r--r-- 1 bin 75376 Apr 1 15:43 bmkcvt.exe
-rw-r--r-- 1 bin 2151 Apr 1 15:43 bmkcvt.txt
-rw-r--r-- 1 bin 370 Apr 1 15:43 gopher.bmk
-rw-r--r-- 1 bin 182910 Apr 1 15:43 gopher.exe
-rw-r--r-- 1 bin 75711 Apr 1 15:43 gopher.ovr
drwxr-xr-x 2 bin 512 Mar 22 17:29 icky_old_client
-rw-r--r-- 1 bin 643 Apr 1 15:43 manifest.101
drwxr-xr-x 2 bin 512 Mar 22 17:29 packet_drivers
-rw-r--r-- 1 bin 41929 Apr 1 15:43 pcg3.txt
-rw-r--r-- 1 bin 62341 Apr 1 15:43 pcg3.worddoc
-rw-r--r-- 1 bin 211699 Apr 1 15:43 pcg3.zip
-rw-r--r-- 1 bin 2999 Apr 1 15:43 release.101
226 Transfer complete.
838 bytes received in 0.31 seconds (2.66 Kbytes/s)
ftp> bin
200 Type set to I.
ftp> get pcg3.zip
200 PORT command successful.
150 Opening BINARY mode data connection for pcg3.zip (211699
bytes).
226 Transfer complete.
local: pcg3.zip remote: pcg3.zip
211699 bytes received in 6 seconds (34.47 Kbytes/s)
ftp> quit
221 Goodbye.
C:\gopher: pkunzip pcg3
-----------------------------------------------------------------
+ Page 19 +
At this point, the client software is on your PC's disk. Before
you can use it, you must configure it. This includes specifying
the IP address of your workstation as well as your local
"netmask." If the correct answers for these values are not
obvious to you, contact local computer support for assistance.
Once you have configured the client, you can invoke it by typing
"gopher." Future sessions do not require configuration (unless
you want to change a setting, for instance to choose a different
Gopher server).
Unfortunately, use of campus or corporate computer networks
is not as simple as plugging a cable into an outlet. There are
many local variations. Some sites use public domain TCP/IP
packages; some have site licenses for commercial products. Some
departments have local area networks that are gatewayed into the
larger Internet environment. Technical support varies based on
computing platform. New Gopher users should consult local
network support specialists for assistance.
6.0 How the Gopher Protocol Works
The Gopher protocol rests on the metaphor of a file system. As
we've seen, a Gopher server delivers a menu in the form of a list
of menu items. When a Gopher client connects to a server, it
opens a TCP connection to a specified "well-known
port"--typically port 70. Once the connection is established,
the client then transmits a "selector string" that specifies what
it wants to see. If it is the initial connection to a Gopher,
the client sends a null selector string. This tells the server
to deliver the highest level, or root, menu to the client. Once
the server has finished sending the list of items, the connection
is closed. The client then displays the document titles on the
user's console, and the user is free to click on items of choice.
The information sent by the server includes the following
fields:
<type> <Document Title> <selector string> <server domain
name> <server port number>.
+ Page 20 +
One line of this form is delivered for each document. The
initial field is a one-byte document type identifier. The type
field is concatenated with the beginning of the title field;
other fields are separated by the ASCII tab character. The
Document Title field is the descriptive text that the client
should display for each item. The "selector string" is a string
of characters, usually derived from the location of the document
in the server's file system, that can be used to uniquely
identify the document for retrieval. The server domain name is
simply the domain address of the server. The port number is a
concept common in TCP/IP server nomenclature; the Gopher server
"listens" on a specified port for transactions. (The Internet
Assigned Numbers Authority, or IANA, which concerns itself with
such issues, has assigned Port 70 as the standard Gopher port,
though a given server may use another port--or ports, if a single
machine runs multiple Gopher services.)
For each document descriptor delivered by the server, the
client inspects the one-byte type designation. If a document is
of a type the client can't handle, the client simply omits that
document from its list of titles. For instance, audio files are
not currently supported via PC Gopher III. If a user points PC
Gopher III at a directory that contains such files, those titles
will not be shown to the user. Since the user can't select it,
there's no frustration with impossible requests. (Although the
protocol specification calls for this behavior, some clients,
such as the public curses client, do not in fact omit such items.
This may be useful in some cases. For instance, the user may
want to download an item via the curses client for later use
outside the Gopher session.)
The process used by Gopher clients and servers can be
envisioned in Figure 7.
+ Page 21 +
-----------------------------------------------------------------
Figure 7. Gopher Client/Server Interaction
-----------------------------------------------------------------
Client sends "selector string" to server via
TCP to port 70.
===============================================>>>
_______________ ________________ ____________
| | ( ) | |
| Client | ( Campus Ethernet ) | Gopher |
| (user | ( or ) | Server |
| workstation) | ( The Internet ) | |
| | ( ) | |
|_______________| ________________ |____________|
<<<================================================
Server sends back document to client,
then disconnects.
----------------------------------------------------------------
The selector string tells the server what the user wants to see.
The delivered document selectors, in turn, are the unique
identifiers needed to cause the server to deliver each upon
request. Once the server has delivered a document (whether it
be folder, plain text, or otherwise), it has done its job for
this transaction, so it disconnects. The Gopher server does not
retain any information about the client across transactions--it
is said to be "stateless." This aspect of the Gopher design is
the key to Gopher's efficiency--the server is only connected to
the user long enough to serve a particular request, and it does
not pay the high overhead cost of having hundreds or thousands of
users "logged in" at once. This highly efficient model allows
relatively small workstations to function as Gopher servers,
handling millions of requests per week from thousands of users
across the Internet.
+ Page 22 +
7.0 Gopher Document Types
The Gopher document types that have been defined so far are shown
in Table 1.
-----------------------------------------------------------------
Table 1. Gopher Document Types
-----------------------------------------------------------------
0 File
1 Directory
2 CSO phone-book server
3 Error
4 BinHexed Macintosh file
5 DOS binary archive
6 Item is a UNIX unencoded file
7 Index-Search server
8 Text-based Telnet session
9 Binary file
+ Redundant server
T Text-based TN3270 session
g GIF format graphics file
I Image file
Source: Internet Request For Comments document, RFC 1436.
-----------------------------------------------------------------
In practice, other document types have also been adopted (e.g.,
"M" has been used for MIME mail documents).
As Table 1 illustrates, the term "document" is used broadly
to include any type of resource that can be accessed by the
Gopher. Here is a more detailed explanation of some of the
important document types.
o File. This is a simple ASCII text file, which is
displayed on the user's workstation using some sort of
file browser.
o Directory. This is a list of documents that is used to
construct a Gopher menu. When a directory item is
selected, the server sends the client the list of items
in that directory. Included with each item is the
information that the client will need in order to fetch
the document when the user requests it.
+ Page 23 +
o CSO phone book server. Named after the Computing
Services Organization at the University of Illinois,
CSO provides a client/server protocol for searching a
phone database. Gopher recognizes this protocol and
lets the user interact with a CSO server in order to
look up information.
o Text-based Telnet session. This document type allows a
Gopher to present a list of host services that accept
Telnet as a remote access protocol. For instance, a
list of Internet-accessible online catalogs.
o Text-based TN3270 session. A variant of Telnet,
TN3270, is required to connect to IBM mainframe hosts.
Support for this form of connection was incomplete
early in the life of Gopher but has become pervasive in
the last several months. (TN3270 support is important
because many online catalogs and other database
services reside on IBM mainframes. These days, when
traditional mainframe-based services are looked upon
with derision by some in the networked information
community, mainframes are sometimes referred to as
"legacy systems." But a lot of valuable information is
still stored on those legacy systems, so connectivity
to them is necessary.)
There are also document types for PC (DOS binary archive),
Macintosh (BinHex file), and UNIX (unencoded file) files; graphic
files (GIF); searchable databases (index-search server); and
backup Gopher servers (redundant server).
Note that the case of the document type identifier is
significant. Because each document descriptor line contains the
name of the server where that document is located, it is easy for
a Gopher server to point to documents stored far and wide. For
instance, a Gopher server at Mythical State University might set
up the document types for a root menu as shown in Table 2.
+ Page 24 +
-----------------------------------------------------------------
Table 2. Example Document Types
----------------------------------------------------------------
Type: 0
Document Title: About this Gopher
Selector: 0/about_MSU
Server: gopher.mythical.edu
Port: 70
Type: 1
Document Title: Fun & Games
Selector: 1/fun
Server: gopher.tc.umn.edu
Port: 70
Type: 1
Document Title: MSU Campus Events
Selector: events
Server: events.mythical.edu
Port: 70
Type: 2
Document Title: MSU Telephone Directory
Selector: [blank]
Server: cso.mythical.edu
Port: 105
Type: 7
Document Title: Search MSU Gopher
Selector: titles 7/ts
Server: gopher.mythical.edu
Port: 70
-----------------------------------------------------------------
Note that the Document Title is the only field that clients
display by default. The combination of Selector, Server, and
Port describes the document uniquely. Note also that the
selector string consists of whatever text the server wants to
receive in order to deliver a document. For Unix-based servers,
this string is prefixed by the type of the document and a slash.
Finally, note the variety of servers shown in this example.
Often a Gopher administrator will store items peculiar to his or
her domain on the same server machine as the Gopher server, but
this is not essential. It is common for documents of local
interest to reside on several servers, as shown above.
Theoretically, a server could offer only documents that reside on
other Gopher servers.
+ Page 25 +
Because the Gopher design calls for a simple protocol built
on TCP/IP, it is possible to test the behavior of servers without
even using a client. The reader might want to try connecting to
a Gopher server "manually" to see how this works. For instance,
if you were to open a Telnet session to "gopher.micro.umn.edu 70"
and then press the return key, you would see the initial menu for
the main University of Minnesota server displayed in raw form.
Most Gopher clients provide an "Item Info" option that
displays the selector string that pulls up the current document.
This can be useful when you want to know where a given document
originates. It also makes it easy for a Gopher administrator to
add a local pointer to a newly discovered, useful item.
8.0 Setting Up a Gopher Service
It is relatively easy for a developer to implement Gopher client
or server software. The protocol is also very efficient in its
demands on the server and the network. This simplicity extends
to establishing a new Gopher service: it is also easy for an
information provider to set up a Gopher server. Some Gopher
administrators report being able to bring a server online within
an hour or two of downloading the server installation kit.
Typical Gopher servers are UNIX workstations of one sort or
another. The University of Minnesota relies upon Macintoshes
running A/UX and NeXT workstations for the most part. Other
popular server platforms include Sun workstations and IBM
RS/6000s. The Gopher server code has also been implemented on
the PC, but this platform is relatively uncommon as a server.
Servers have even been implemented on IBM mainframes, both under
the VM/CMS and MVS operating systems.
+ Page 26 +
The standard Unix-based server code is written in C. It can
be found at the same repository as the client code
(boombox.micro.umn.edu), and it can be installed on a variety of
platforms with little modification. The Frequently Asked
Questions (FAQ) file often includes tidbits on peculiarities of
installation on particular platforms. The news group
(comp.infosystems.gopher) also contains discussions of
installation issues. New server administrators will want to
consult the news group archive (see Figure 3).
Numerous tools have been created that assist in managing
Gopher servers. For example, tools that analyze logs, improve
indexes, and extend support delivery of calendar-based
information are available. Some of these tools can be retrieved
from the University of Minnesota's FTP server. Others,
particularly short Perl scripts, are posted by the authors on
comp.infosystems.gopher. Thus, the discussion group is not only
a source of accumulated wisdom. It also is a repository of
helpful tools.
Gopher administrators announce new servers on the following
lists:
gopher@ebone.net (European servers)
gopher@boombox.micro.umn.edu (All other servers)
The announcement should include the name of the Gopher server,
its Internet address, and its port number. The name can include
labels such as "(experimental)" or "(Under Construction)" as
appropriate. New administrators may want to review Gopher server
names listed in "All the Gopher servers in the world" to see what
sort of names others have chosen before picking their own.
Gopher administrators face many challenges. One of these is
how to effectively organize the Gopher menu hierarchy. Another
challenge is how to convert documents from whatever format the
owner of the information prefers to flat ASCII, which is
currently the least common denominator document format--the
format that all computing platforms can cope with. Prospects for
delivering documents in PostScript are discussed below; in the
absence of that sort of advance, perhaps the best advice for the
Gopher administrator is to insist that document owners do the
translation to flat ASCII, rather than taking on that chore as a
part of running a Gopher service.
+ Page 27 +
9.0 Goph
er's Origins
Computer Center staff at the University of Minnesota began
discussing the need for something like Gopher in early 1991.
They wanted an online mechanism for "publishing" hints on
computing services at the university. Mark McCahill, project
leader for the group that developed Gopher, says the goal was to
find a scheme that was more efficient than one-to-one consulting
or conventional handouts and short courses. At the time, another
group at the university was proposing a mainframe-based solution
for campus document delivery. The group designing Gopher wanted
a simple, network-based scheme that supported browsing of
available documents. They also wanted to build a service that
was fun to use, so that a critical mass of users would develop.
The original Gopher team included Farhad Anklesaria, Paul
Lindner, Daniel Torrey, Bob Alberti, and Mark McCahill.
The developers' earliest discussions produced a goal of a
simple protocol--easy to understand, describe, and implement.
They decided upon a client/server model: a client would open a
Telnet connection to the server, request specific information,
receive and display the information, and disconnect. The initial
model called for only two document types: text files and folders
(subdirectories). Thus, from the beginning, the developers
envisioned a mechanism that would deliver lists of files and
directories upon request. The client/server model would provide
for sessions lasting only long enough to deliver that list to the
user's client software. These aspects of the Gopher model have
endured.
The University of Minnesota design team held their first
serious meetings during the first week of April 1991. The Gopher
team proceeded to work on implementing the first servers and
clients. The goal at this point was to build a working prototype
that could readily be discarded; the team assumed that whatever
they produced might be replaced by something better within a
year. The team spent quite a few 16-hour days on the project.
By the last week of that month, they had prototype Gopher clients
and servers working. Initially, there was a Macintosh client and
server, a UNIX client and server, and a PC client.
By late April, the Gopher developers decided that some sort
of search mechanism was also needed. NeXT workstations were seen
as an appropriate choice for servers, because the built-in
Digital Librarian offered a highly functional search engine. The
developers also decided Gopher should support telephone directory
searches, and they settled upon the CSO telephone directory
search protocol, already in use at numerous universities, as the
best way to implement online phone books.
+ Page 28 +
These different document types--text, folders, and CSO
searches--would be sufficient to define a Gopher that could
deliver documents stored on a single server. But, from the
start, the protocol allowed a server to point to another server
as the physical home of a given document. This allows a Gopher
to include services that may be scattered across the Internet all
in one list. It also makes possible a directory of other
Gophers, any of which is a keystroke or a mouse click away.
But the developers thought about providing ways to connect
to existing database servers on campus, such as a university's
online catalog. They decided to include a document type that was
itself a Telnet session to another host computer. To round out
the collection, a document type for transferring Macintosh or PC
binary files was included. The original protocol was designed to
be extensible; the one-byte data type field could potentially
support 255 different data types. A draft Gopher protocol
specification was released in spring 1991.
The original Gopher team divided their development efforts.
Torrey implemented the client for MS-DOS, and Bob Alberti wrote
the first UNIX curses client. Anklesaria wrote the initial
server and client for the Macintosh. Lindner developed the
initial UNIX server code. Besides serving as project leader,
McCahill set up the first index server using the Digital
Librarian tool on the NeXT and assisted with early development of
the Macintosh client. Despite this division of labor, the group
worked as a team on problem solving and common issues.
Delivery of sound via Gopher was born during the early
development phase. One weekend the team member doing most of the
server code, Paul Lindner, wanted to hear some music in his
office, which is several rooms away from the communal CD player.
His NeXT workstation was capable of playing sounds, and there was
a CD player available on a workstation in another room. A few
hours later he had implemented the sound data type, and Gopher
was capable of playing music across a real-time Internet link.
The first Gopher production services were in place at the
University of Minnesota by late summer of 1991. Gopher was
announced to the world via the campus-wide information systems
mailing list (CWIS-L@WUVMD) in July 1991. A USENET news group,
alt.gopher, was started. Computer system administrators from
around the Internet began to learn about Gopher. The code was
made available for others to try, and Gopher servers began
popping up in various places. By early 1992, Gopher was no
longer a prototype but was becoming a tool of choice as
universities sought ways to implement campus-wide information
systems. Steve Worona of Cornell Information Technologies says
that Cornell was about to design a protocol that would allow them
to move their pioneering CUINFO mainframe campus information
service to a network/workstation environment, "but then we found
out about Gopher, and it was exactly what we were looking for."
[1]
+ Page 29 +
The new TurboGopher client for the Macintosh provided a
learning experience for the developers, because much of the
testing took place over 2400 bps dial-up SLIP connections. This
slow link exposed the ways in which the client blocked efficient
transfer of data. The client was modified, and it now offers
very impressive performance on high-speed networks. The
University of Minnesota team believes this to be the fastest
client now in service. Recent work on TurboGopher has been done
by University of Minnesota staffer Dave Johnson; additions
include foreign language support.
10.0 Gopher+
In August 1992, the regional computer network CICNet sponsored a
Gopher Workshop in Ann Arbor, Michigan. Invited attendees
included Gopher implementers at the various CICNet institutions
as well as Gophernauts from Brown, Yale, Cornell, Princeton,
Rice, the University of Washington, the University of North
Texas, and other institutions. Mark McCahill and Farhad
Anklesaria attended from the University of Minnesota. At that
conference, the University of Minnesota developers presented
Gopher+, their vision for how to extend Gopher beyond its
original design.
The original Gopher design, with its one-byte document type,
was adequate to meet many of the needs of the community. But
there were many demands for additions to the protocol, to handle
everything from PostScript files and various image files (e.g.,
GIF and JPEG) to global document attributes, such as author name
and document expiration date. Rather than embed each and every
requested extension in the protocol, the University of Minnesota
team devised a mechanism to support general ways to add them to
the protocol. McCahill says that the team had been working on
Gopher+ throughout 1992, but the advent of the workshop caused
their ideas to gel.
Gopher+ adds new, named fields to the simple one-byte item
descriptor in basic Gopher. If a client appends an exclamation
mark to a selector string, the Gopher server is expected to
deliver an Attribute Information block. The first named field,
+INFO, is required; it resembles the descriptive line sent by the
old protocol. Other named fields that have been suggested for
Gopher+ include +ABSTRACT, which would be a textual abstract
describing the document; +ADMIN, which would be the name of the
owner of the document; and +DATE, which would be the date the
document was last modified. These global document attributes
would help administrators maintain and describe documents, and,
after appropriate client enhancements, would help users select
documents of interest.
+ Page 30 +
The University of Minnesota announced it would act as a
central registry of Gopher+ data types; anyone proposing to
implement a new named attribute field will submit it for
registration to the Gopher team. This model allows cooperative
uses of new fields as agreed to by the Gopher community. It also
potentially allows a given site to implement a particular field
in its clients and servers that would be of no interest to anyone
else. As always, a client would only handle the information it
knows how to deal with. If someone adds a +HAIRCOLOR attribute,
a Gopher+ client would be free to ignore it. Note that a Gopher+
field could be a simple textual value, or, like a document under
the basic protocol, it could point to another Gopher+ server.
Besides providing a mechanism for supporting global document
attributes, Gopher+ is intended to support alternate views to a
document. For instance, a special named field called +VIEWS will
support versions of a document in different languages. With
+VIEWS a document could be offered in a variety of formats, from
flat ASCII to PostScript.
Beyond the global attributes and alternate views functions,
Gopher+ also provides a mechanism for interactive queries. A
Gopher+ server can interrogate a user for specific information
such as a password, or it could even serve as an interface
between a user and an interactive process on another host. This
+ASK support includes options for prompting for file names or for
the user to make a choice among a range of options.
In February 1993, the University of Minnesota Gopher team
announced the first clients implementing the Gopher+ protocol--a
version of TurboGopher (for the Mac) and a version of the UNIX
client. Server code is also available, and the production
version of the University of Minnesota's Gopher points to a
demonstration Gopher+ server. Users with non-Gopher+ clients can
safely point to Gopher+ servers, but they will not be able to
view the Gopher+ documents.
There has been some criticism of the Gopher+ protocol
extensions. In particular, some have argued that instead of
defining the +VIEWS scheme under Gopher+, the Gopher community
should rely upon MIME (Multipurpose Internet Mail Extensions).
Originally proposed as a way to allow arbitrary 8-bit files to
survive transit over Internet (SMTP) mail, MIME is being deployed
widely and may serve as a standard way to handle multimedia files
on a variety of platforms, whether the files are delivered via
e-mail or otherwise. Others question whether there really needs
to be a Gopher+ registry. If it does need to exist, some argue
it should be at the official Internet registry, the IANA.
In April 1993, the University of Minnesota sponsored a
second Gopher Workshop and Conference. Participants at the
Workshop urged the developers to consider adoption of the MIME
content types and registry scheme instead of "rolling their own"
types and registry. The Gopher team agreed to "strongly
consider" use of MIME content type attributes.
+ Page 31 +
In the short term, the University of Minnesota intends to
act as the registry for other global document attributes (such as
the owner of a document), but they have stated their willingness
to use IANA eventually.
Whether Gopher+ is deployed in its current form or with
changes to the syntax and registration process, it is clear that
it will allow Gopher to be extended to handle document types that
have not yet been envisioned. It will improve the ability of
Gopher administrators to organize documents. It will also allow
basic improvements in the technology, providing a framework for
improved navigation and interfacing to interactive services. An
RFC describing the base Gopher protocol has been issued (RFC
1436). Mark McCahill says that, after minor corrections are made
to that document, the base protocol will be frozen. Gopher+ is
considerably more fluid. It will be interesting to watch its
evolution.
Along with Gopher+, the University of Minnesota team has
also developed a mechanism for allowing "lightweight"
authentication of users for access to protected documents. For
instance, some vendors may insist that their documents can only
be read when users have typed in a unique password assigned to
them. The AdmitOne Authentication scheme lets a user obtain a
"ticket" that allows access to restricted documents. The
AdmitOne scheme uses encryption to avoid sending passwords over
the network. It also provides a way that a client can reuse a
ticket for subsequent transactions. Critics of AdmitOne have
pointed out schemes for defeating the security of AdmitOne, some
rather elaborate. One claim is that security cannot be provided
by a client and a server alone--a trusted third party is
required.
11.0 Organizational Issues
The greatest strength of Gopher--its ability to easily present a
single menu whose constituent documents reside far and wide on
the Internet--also presents some interesting challenges. Gopher
is being used at many universities to implement campus-wide
information systems (usually referred to by the acronym CWIS,
pronounced "kwis"). Each site setting up a CWIS under Gopher
faces the challenge of devising an organizational scheme that
embraces all the local documents and host services of interest as
well as the many documents and services available over the
Internet.
+ Page 32 +
Some sites have adopted a simple model for the root menu.
This yields a short and simple initial menu, such as:
About Gopher
The Campus
The Community
The World
This elegant approach is appealing in its simplicity. Of course,
to some extent, the scheme simply moves the problem of where best
to put various documents downstream. Even with these simple
categories, some items can be hard to place. Where do you put a
gateway to your student e-mail service? What if you have an
events calendar that integrates campus and community happenings?
Where does the local weather go?
At the other end of the spectrum, a site might choose to
have a broad set of offerings on the root menu, making more
documents accessible with fewer mouse clicks. Such a menu
structure might look like this:
1. Gopher at Michigan State University.
2. More About Gopher (Documents & Navigation Tools)/
3. Keyword Search of Titles in MSU's Gopher <?>
4. About Michigan State University/
5. MSU Campus Events/
6. News & Weather/
7. Phone Books & Other Directories/
8. Information for the MSU Community/
9. Computing & Technology Services/
10. Libraries/
11. MSU Services & Facilities/
12. Outreach / Extension / Community Affairs/
13. Network & Database Resources/
+ Page 33 +
This sort of scheme tries to bring commonly accessed documents to
the front. The user need not search through multiple menus to
find today's weather or the campus phone book. The very first
item is a text file with introductory material, so the new user
doesn't face a menu full of folders. A keyword title search
allows users to find documents no matter where they are stored in
the hierarchy. On the other hand, the user confronts a much
busier initial screen, which may be daunting in its length and
complexity. Depending on the client's default window size, the
initial screen may not even fit on the menu window, forcing the
user to scroll to see all choices.
Users may find the bookmark facility offered by most clients
to be a useful way to customize their view of a Gopher. Gopher
administrators can also make liberal use of indexes--both
document title indexes and full-text indexes--in order to make it
easy for users to quickly locate data without having to hunt
through the hierarchy. These tools can help, but a balanced
hierarchy that reflects local needs is a worthwhile goal, even
though there is no universal agreement on basic issues such as
whether a depth-first or breadth-first organization is best. In
any case, the process of building a CWIS under Gopher is much
more likely to succeed if a campus-wide committee helps design
the structure. For instance, a site might want to include staff
from the central computing organization, the library, university
relations, departments that run their own Gophers, and so forth.
A committee can help ensure needs of various campus
constituencies are met.
While an organizational scheme for a CWIS must address the
peculiar needs of each campus, most Gophers also allocate part of
their directory tree to "Internet Resources" (or some similar
name to serve the same purpose). Gopher administrators are
beginning to realize that it does not make sense for each of them
to come up with a local scheme for organizing all the online
resources of the Internet. First, this is not practical; second,
if a common organizational scheme can be devised for all of
Gopherspace, then users will not confront wildly differing
Internet directory structures as they move from campus to campus.
Note that not all Gophers aspire to the scope of a
campus-wide system. In some cases, the documents on a Gopher are
mostly related to the special purpose of the sponsoring
institution (e.g., the Electronic Frontier Foundation, the Well,
and the National Institutes of Health). Such Gophers are
inherently more narrowly focused than a university's CWIS tends
to be.
+ Page 34 +
Other administrators are mounting "subject Gophers" that may
cover a single subject or a variety of subjects of general
interest to users, but not documents pertaining to a particular
campus. For instance, Don Gilbert of Indiana University has
deployed a Gopher that is dedicated to materials on biology, and
this server is becoming a useful resource for the biological
sciences community. Sue Davidsen of the University of Michigan
Graduate Library has built a subject Gopher that delivers census,
business, and social science data. Known as Go M-Link, this
Gopher mainly serves public libraries in Michigan. Subject
Gophers in many cases have the most intuitive organization
schemes.
The use of the Internet to deliver electronic journals
presents a special organizational challenge for the Gopher
community. Discussions on how to manage and organize a set of
e-journals are underway. Some propose the venerable Dewey
Decimal Classification; some suggest the Library of Congress
Classification Schedules; others like the Universal Decimal
Classification; and others are experimenting with schemes of
their own devising. CICNet has announced a project to archive
electronic journals via their Gopher. Billy Barron of the
University of Texas at Dallas is building this archive, and he is
experimenting with organizational issues. [2] His initial effort
uses the LC Classification scheme. One group of Gopher
administrators and librarians from CICNet, NYSERNet, and other
institutions are exploring alternative approaches to Gopher
taxonomy.
Some librarians contend that any attempt to fit documents
drawn from all areas of human endeavor into a formal
classification scheme is not an appropriate model for mounting
networked information. Marty Courtois, a librarian and database
coordinator at Michigan State University, observes: "Library
classification schemes such as the Dewey Decimal System and the
Library of Congress classification are good systems for finding
materials on the shelf and are necessitated by the fact that a
single book can only be placed in one location." [3] With a
system like Gopher, cross-references can be set up as simple
alternate links. Thus, a set of subject headings based on a
controlled vocabulary can make materials far more accessible to
the user. As Courtois puts it:
It's simply easier to browse a classification list to look
for "Biological Sciences" than to have to know that "QH300"
represents that field. It's like giving the user a chance
to look in the card catalog and the shelves at the same
time. [4]
+ Page 35 +
The world of networked information is new and evolving. Some
organizational schemes that seem obvious to an administrator may
be suboptimal for the user. For instance, there is a tendency to
categorize networked information servers based on their location
or on the underlying technology. For instance, you might find a
Gopher menu that offers:
Other Gopher Servers
Non-Gopher Campus Wide Information Systems
WAIS-based information
World-Wide Web
The user of course is interested in information, not the
technology that presents it. In the long run, providers of
networked information resources need to find ways to organize
materials by subject matter, not by whether the data resides in a
Gopher, WWW, WAIS, or some other technology. As Marie-Christine
Mahe of Yale University observes, "A Gopher that splits CWISes
along technical lines is equivalent to a supermarket that would
shelve tomato sauce in different aisles, according to whether it
was in a can or in a glass jar." [5] Mahe believes that when
Gopher uses standards such as Z39.58, it will be easier to
provide uniform access to data stored under disparate systems.
In the meantime, she argues that Gopher administrators should use
topical organization whenever possible.
One could imagine a division of labor among Gophers, as
follows: (1) publisher Gophers would distribute original material
in one or more subject areas; (2) single-subject Gophers would
organize and provide access to network resources for a subject
area; (3) index Gophers, such as Veronica, would allow users to
search for resources by keyword instead of browsing; (4) master
Gophers would link users to single-subject and index Gopher
servers; and (5) CWIS Gophers would specialize in documents and
services that pertain to each campus (they would have links to
master Gophers to provide access to Internet resources).
Whether this happens or not, it is clear that there must be
more recognition of the specialized roles that Gophers can play.
If every Gopher administrator tries to provide both original
documents and organized links to Internet resources, these
efforts are doomed to fail.
+ Page 36 +
12.0 Navigational Enhancements
Gopher provides an effective mechanism to allow an administrator
to provide a hierarchical browsing list, for a campus, for the
Internet, or both. But the organizational scheme carefully
designed during months of deliberation by a campus menu design
team may bear no relation whatsoever to the organization of a
given user's brain. Even when the organizational scheme is
suited to the user, the process of searching for information
across many Gophers can be tedious. Recent developments have
addressed both concerns.
12.1 "Road Map" and TS/TB
In July 1992, Dennis Boone of Michigan State University
implemented a "Road Map"--a representation of an entire Gopher's
directory structure in a single text document. This allows users
to read the map and get a feel for the lay of the land. Also
that month, Boone implemented a Gopher title search tool. Known
as "ts/tb," the title search allows the administrator to prepare
keyword search indexes for the entire Gopher tree or for any part
thereof. The user wanting to find the schedule for the campus
opera society can do a keyword search on "opera," and all titles
including that word will be served up as a menu. The title
search tool has been adopted for use at a number of sites. One
shortcoming is that document titles are pulled up from wherever
they appear in the menu hierarchy, and they are presented without
putting them in the context of the menu hierarchy. However, this
usually does not lead to confusion.
12.2 Veronica
In November 1992, Steven Foster and Fred Barrie of the University
of Nevada announced a service that could search document titles
across many Gopher servers. Their original code was a
modification of Boone's title search. Where Boone's index
deliberately limits itself to one Gopher server, they devised a
mechanism to provide a single title index that could span many
Gopher servers. The Nevada team christened their tool Veronica,
which they say is an acronym for "Very Easy Rodent-Oriented
Netwide Index to Computerized Archives." Just as Archie surveys
anonymous FTP servers for their list of holdings, Veronica must
go out and poll its target servers periodically in order to build
a database. A user connecting to Veronica specifies a keyword to
search for, say for the word "biology," and gets a list of
document titles from throughout Gopherspace that match.
+ Page 37 +
At this point, Veronica is not without its problems. The
most noticeable problem is performance. As of this writing,
there are two Veronica servers for the entire Internet and these
servers are often quite busy. It can take several minutes to get
a response to a Veronica query at busy times. Of course, if the
search eliminates many minutes (or hours) of manual browsing, a
wait of several minutes may well be worth it. Steve Foster
observes that users have told him they are willing to wait for
the results of a search of all of Gopherspace, assuming the
results are accurate.
Another concern is discerning the meaning of titles listed
as the result of a Veronica search. As with the single-Gopher
title search, the document titles are shown stripped of their
hierarchical context. Within one Gopher server this is not
necessarily daunting. Do a Veronica search on "presidential,"
however, and you'll find items ranging from the 1992 Presidential
debates to presidential searches at various campuses. The labels
may not provide enough context to make clear the location or
purpose of a given document. The user ends up having to select
unwanted documents just to determine what they contain, and even
then there may not be sufficient context within the document.
Initially, Veronica did not resolve multiple references to a
given document down to one listed item. Popular items are
pointed to by many Gophers, so a Veronica search might yield 100
pointers to the same document. The Veronica developers modified
the software in December 1992 to fix this problem: all references
to a particular selector string/host are collapsed to one
listing. This does not solve the problem of sites that make
separate local copies of documents they find on the network; each
such copy is indexed separately by Veronica. The only hope for
solving that problem is widespread adoption of a Uniform Resource
Number scheme. (The Internet Engineering Task Force is working
to define such a numbering scheme, which, with companion Uniform
Resource Locators, would allow for agreed-upon ways to number and
to locate Internet documents and services.)
Finally, Veronica is not currently consistent in the search
results it delivers to the user. Part of the problem is that
Veronica, like most Gopher indexes, relies on the public domain
WAIS search code, which returns a "relevance score" rather than
an absolute answer as to whether something was found. At one
point, the two existing Veronica servers yielded differing
results for the same searches. Inconsistent results may also
arise from the fact that Veronica may be unable to do its
periodic survey of a given server. One proposal for addressing
this problem calls for a new Gopher document type, the Veronica
index, which would be delivered to a polling Veronica server in
one operation. This would be a much simpler, more efficient
transaction than having the Veronica server manually traverse the
entire directory tree of each Gopher server whose titles it wants
to survey.
+ Page 38 +
Despite these shortcomings, Veronica represents an exciting
development. Already users are finding it far more efficient
than browsing innumerable menus when searching for specific
resources in Gopherspace. Proof comes from the results of recent
Internet Hunts. These monthly quizzes, issued by Rick Gates of
the University of California at Santa Barbara, challenge users to
find out what information servers on the Net can answer
particularly arcane questions. (For example, "Who is the author
of the only book held by Victoria University of Wellington on the
training of sheep dogs?") Increasingly, the winners of the Hunt
have exploited the power of Veronica to enhance their burrowing
through Gopherspace.
Many Gopher servers now provide a pointer to Veronica under
"Other Gophers" or an equivalent folder. (The Nevada server is
located at veronica.scs.unr.edu, port 70; use the selector string
"1/veronica" to access the server.) The Veronica developers are
exploring setting up several servers around the Internet, to
balance out load factors. With the number of Gopher servers
growing daily, the list of servers in production has become a
management issue in its own right--there are currently over 1,100
servers. Recently the staff at the University of Minnesota
reorganized the "list of all Gopher servers in North America,"
breaking it up by state. This makes browsing easier for some
purposes, but if you are looking for, say, Johns Hopkins
University, and you do not know it is located in Maryland, you
may want a different path. (Indeed, for most purposes, the
geographical location of the server is irrelevant to the user's
query.) Dennis Boone has implemented a global keyword index of
Gopher site names to allow a user to quickly find a known site
regardless of where it is located. (This service is available as
"7/internet/others/ts" on the gopher.msu.edu server. Gopher
administrators may want to add pointers to this index.)
12.3 Jughead
In March 1993, Rhett Jones of the University of Utah announced a
Gopher title search tool called "Jughead." Jughead can index a
single Gopher or all of Gopherspace, as Veronica does.
John Doyle of Washington and Lee University has used Jughead
to create several indexes of Gopherspace by document type (e.g.,
Telnet session, CSO phone book, and index). His Jughead server
is found at liberty.uc.wlu.edu, port 3002.
13.0 Quality of Service Concerns
Gopher has come a very long way in a very short time. Because
servers have been deployed around the Net for only about sixteen
months, many services are still experimental. A user may stumble
upon a document that sounds just right using Veronica, only to
discover in dismay that the needed server is consistently down.
+ Page 39 +
To some extent, this is inherent in networked information.
And perhaps users should learn to expect to find resources that
are unavailable from time to time. As Nancy John of the
University of Illinois at Chicago has observed, patrons of
libraries have long been used to the idea of locating a
particular book they want, only to find that book has been
checked out by another patron. [6]
Still, administrators confront choices that may affect
reliability of service. The Gopher model encourages distributed
deployment of services across many servers. It is tempting to
place documents on a wide variety of Gopher servers, across a
campus and even within departments. But as Joel Cooper of Notre
Dame University points out, some forms of information are vital
"corporate data"--data that must be reliably provided for the
good of the enterprise. [7] For instance, Gopher presents real
opportunities for saving trees by replacing printed matter. But
if the phone book server is located in a locked office that is
inaccessible at night, who will reboot it when it crashes?
Gopher administrators may well want to put documents that are
vital to their institutions' business on a central server,
perhaps in an area staffed by full-time computer operators. By
using automated document posting processes (either via e-mail or
FTP), the administrator can make posting easy for information
providers, while utilizing carefully managed servers.
Even the best maintained server will experience outages.
Gopher clients determine that a server is down simply by "time-
out" criteria--they wait for a predetermined period of time and
display an error message if the Gopher server doesn't respond.
Some clients allow interruption of a query if the user does not
want to wait for the entire time-out interval. It would be
desirable if all clients allowed the user to configure the time-
out interval.
The Gopher protocol provides a mechanism whereby a server
can deliver two selector strings for a given document. In this
way, a site could offer a primary and an alternate server for
critical information. So far, this feature of Gopher has not
been widely exploited, but it is worth noting that the University
of Minnesota now runs a server that replicates the documents
offered at Gopher Central. (The backup is gopher2.tc.umn.edu,
port 70.)
Prudent Gopher administrators will also provide for regular
backup of the server software and data files. Any production
data resource demands regularly scheduled incremental and full
backups. Again, centrally located servers may be in the best
position to be backed up, perhaps by staff who already perform
such backups for other production hosts on a daily basis.
+ Page 40 +
Reliability of service is one issue; quality of content is
another. In many cases, Gopher administrators view themselves as
publishers, and they rely on the original providers of documents
to provide high-quality information. Of course, the quality of
documents delivered can vary wildly. Administrators can try to
set standards for quality of content and for currency of
information, but these can be hard to enforce. In some cases,
removal of documents, while a blunt instrument, is the only
answer to this problem.
Again, the ability of Gopher to point to other documents
becomes an issue. Just about anyone can declare an electronic
serial to be an e-journal. By what standard do we decide whether
to point to it in a Gopher? Include all journals? Those that
manage to produce two issues? Those with ISSNs? Those that
appear to be "scholarly"? Those that are peer reviewed? Over
time, librarians will probably have to apply the same sort of
collection development procedures to online information as they
do for their print holdings. Although most e-journals are
currently delivered without a fee, there are costs to including
substandard material--the human and machine costs of mounting the
material as well as the time the patron spends avoiding the
chaff.
Librarians face the interesting question of deciding whether
to list networked information resources in general, and
Gopher-based services in particular, in their online catalogs.
Already some libraries have included selected e-journals in their
online catalogs. With the proliferation of networked resources,
each library undertaking to catalog the Internet faces the same
issues of what ought to be included in the virtual collection
that confront Gopher administrators. Moreover, the effort
involved in preparing a catalog record exceeds by a considerable
margin the cost of adding a Gopher link. In fact, Martin Dillon,
Director of Research at OCLC, has proposed a four-tier approach
to cataloging Internet resources, with the effort expended
proportional to the scholarly value of the item being cataloged.
In brief, these levels are:
1. Cataloging is equivalent to that used for scholarly
materials today.
2. "Brief record" cataloging as used by libraries for
materials not of the highest rank.
3. Cataloging by automated means, supplemented by some human
editing.
4. Catalog record is supplied by item's creator and
collected automatically. [8]
+ Page 41 +
Should libraries undertake to catalog networked resources, they
may wish to adopt a scheme such as Dillon proposes. Moreover,
they may decide to use consortia and specialization so that not
every library takes on the task of cataloging the entire
Internet.
14.0 Privacy and Security Issues
Like many networked information servers, Gopher servers maintain
logs of what documents have been accessed at what time from what
computer. These log records contain the Internet address of the
originating user's computer. These days, many workstations have
only one regular user. Therefore, an Internet address can
correspond to a single human being. Just as libraries have long
had policies to avoid tracking information about an individual
patron's reading habits, Gopher administrators need to take steps
to ensure that users' privacy is not violated. Some institutions
have issued formal Gopher privacy policies. Two of these
institutions are Rice University and Michigan State. (At the
latter, logs are periodically "sanitized"--information is
summarized so that individual accesses are no longer
discernible.)
Some applications in Gopher could best be handled given a
scripting facility. Such a tool could allow a server to cause a
program to execute on the user's workstation. A very simple
example would be to have the workstation's Telnet program type
essential login information after a session is opened (e.g., a
command all users must type to connect to a service on a given
host; for instance, "DIAL VTAM"). However this sort of facility
poses risks: an unscrupulous Gopher administrator could devise a
script that is dangerous or even malicious in execution. Even a
PostScript interpreter could be dangerous, as PostScript is a
language in its own right, able to open and modify files on disk;
the only protection would be a PostScript browser known not to be
able to write to disk.
+ Page 42 +
Administrators also face problems with users who try to use
Gopher as a pathway into machines where they are not welcome.
Any Gopher administrator can trivially add a link to a host that
may prefer not to be made visible. There is a need for a
registry of what sites are willing to accept Telnet sessions from
random users across the Internet--these sites would be considered
fair game for pointers in Gopherspace. (In practice this has not
been a source of widespread concern so far.) Conversely, Gopher
administrators may find that with tools like Veronica, their
documents may take on greater visibility than desired. For
instance a departmental Gopher might offer information intended
for local consumption (e.g., minutes of a faculty meeting) that
is sensitive if viewed from other sites. Where necessary, it is
possible for an administrator to restrict access to readers on a
local network. This is essential for delivery of restricted
licensed information, such as electronic newspapers.
15.0 Electronic Publishing
Gopher is sometimes labeled an Internet document delivery system.
Yet, we are currently forced, for the most part, to deliver
Gopher documents as flat ASCII files. This is because we cannot
assume that there is software on the user's desktop to allow
display of anything more sophisticated. As a result, Gopher
administrators must spend considerable effort "undesktop
publishing" documents that have been carefully made ornate by
information providers. Not only does this slow the posting of
information, it also denies the end user the benefits of
well-designed material. These are serious concerns for Gopher
administrators.
Some sites have begun to experiment with delivering
documents in PostScript form. A public domain viewer for
PostScript is available from the GNU project. It is called
Ghostscript. At this point, this public domain tool has not been
widely deployed, and it does not appear to be a practical
solution for all computing platforms.
+ Page 43 +
Early in 1993, the Adobe Corporation announced a product
called Acrobat, which will be a multi-platform PostScript viewer.
Acrobat revolves around a special "distilled" PostScript file
type that is said to yield documents only 25% larger than
equivalent ASCII files. Additionally, Acrobat will include the
ability to display embedded JPEG images. Acrobat is a promising
tool for moving the online information world into true electronic
publishing, with font changes and embedded images efficiently
delivered. It would make an ideal browser for Gopher-delivered
documents. The key question is whether Acrobat (or competitive
tools) will be priced low enough so as to allow near-universal
distribution.
16.0 Multimedia
The Gopher community has already begun providing networked
multimedia. Early examples include the ability to deliver audio
over the Internet. This has been demonstrated, but it is
currently limited to NeXT or Sun workstations and it requires
fast Internet paths (at least 64 kilobytes per second). Michigan
State University has posted samples from its extensive Vincent
Voice Library, such as Nixon's resignation speech and Kennedy's
inaugural. Most recently, Michigan State mounted audio of the
entire 1992 Presidential debate that was held on its campus,
along with photos of the event, a transcript, and coverage from
the student newspaper.
Many sites have begun using Gopher to deliver still images.
The Fine Arts School of the University of Victoria uses Gopher to
deliver art images to its students. Jeremy Kargon, a consultant
at Johns Hopkins University, has mounted a series of
architectural images via Gopher. The Instituto Tecnologico y de
Estudios Superiores de Monterrey delivers Mexican scenes via
Gopher. Ohio State University will make available a set of
building diagrams for use by their campus community, for instance
to assist in wiring buildings for the campus computer network.
Medical schools are exploring the idea of using Gopher-delivered
images for instructional purposes. The University of Virginia
has "Gopherized" two still-image collections from the Library of
Congress--a set of recent Soviet documents and a collection of
historical items from the Vatican.
+ Page 44 +
Two formats are most commonly used for still image delivery
over computer networks: GIF and JPEG. GIF is the Graphics
Interchange Format popularized by the information utility
CompuServe. JPEG (Joint Photographic Experts Group) is another
standard file format for digital still images, which allows
efficient storage and fairly accurate reproduction. GIF viewers
have been implemented in many commercial, shareware, and public
domain programs on all common computer platforms. JPEG is a
newer standard that is catching up to GIF in terms of prevalence
of viewers. Under current usage, Gopher type "I" refers to GIF
or JPEG files; type "g" refers specifically to a GIF file.
There are two factors to consider when evaluating whether
delivery of still images via Gopher is practical: disk space
consumed and time required to display the image. The GIF format
typically requires 100 KB to 200 KB of storage per image, but the
cost of disk storage is plummeting--large SCSI drives can now be
obtained for less than $1.50 per megabyte. However, even if cost
of disk storage can be borne, one would probably not want to use
GIF or other bitmapped image formats as a medium for delivery of
multiple page documents: GIF viewers are usually too slow to
allow for rapid paging through image files. Depending on the
hardware and the GIF viewer, it can take 5 to 30 seconds to paint
an image. (All other things being equal, JPEG files generally
take more time to interpret and display.) In addition to the
time it takes a viewer to decode an image for display on the
screen, an administrator must also consider the network overhead
of moving 100 KB files for each end-user selection. With
favorable trends in the cost of disk, the speed of processors,
and the bandwidth of networks, Gopher-mediated delivery of still
images will become more viable over time.
Recently, there have been efforts to support network
delivery of multimedia documents. David Lacey of the University
of Iowa has integrated a browser that implements the MIME
protocol. Sample documents mounted at Iowa include photographs
of artifacts from a campus museum, along with descriptive text.
Viewed on color NeXT workstations, these multimedia documents are
rich and crisp. In the PC environment, the UGOPHER client is
capable of launching software that can play audio, and it can
also play MIME files if the user has the Metamail tool installed.
Experiments with compressed motion video are beginning; one site
is experimenting with delivery of Macintosh QuickTime files via
Gopher. Apple has announced a QuickTime viewer for Microsoft
Windows.
+ Page 45 +
The biggest challenge in delivering multimedia information
is the proliferation of formats. In the still-image arena, there
are more formats than there are 35mm camera lens mounts.
Fortunately the GIF format has been popular enough for viewers to
become available for all common workstation platforms. The JPEG
format may soon become deployed as widely. A Gopher
administrator wanting to provide images to the broadest audience
will use GIF at this point.
There is a similar proliferation of audio file formats. The
8 kilohertz mulaw format currently used for Gopher audio delivery
is readily supported on Sun and NeXT workstations. Other
platforms, such as the Macintosh or the PC with Sound Blaster
cards, assume other formats. Some sites are offering files in
Sound Blaster format for PCs so equipped, but these are not
usable on machines that lack that hardware. Gopher+ may make it
possible for a server to hold a file in one form but deliver it
in the format best suited for the user's client software. For
instance, translation among various audio formats is possible
with software such as the public domain Sox utility. It may be
possible with Gopher+ (and a little effort) to devise ways to
archive audio in one canonical form, but deliver it in the
appropriate machine-specific format.
Large, complex documents in Gopher reveal one shortcoming of
the current technology: Gopher needs a mechanism for delivering a
document in "chunks." Currently an entire document is delivered
when the title is selected by the user. Consequently, a book or
other large text must be artificially split into separate chapter
documents (or further). An audio document must be split either
by arbitrary time slice or based on content. It would be better
if large, complicated documents could be treated as a single
document, or, at the user's choice, viewed based on underlying
structure. Some sort of table of contents field, analogous to
the index markers on compact discs, might be used. With the
deployment of Gopher+, there is the potential for adding this
sort of support.
+ Page 46 +
17.0 Non-Gopher Client Technologies
We saw earlier that Gopher is best utilized when the user takes
advantage of specialized client software. Recent developments in
the area of non-Gopher client technology are worth noting.
At the Fall 1992 meeting of the Coalition for Networked
Information, VTLS demonstrated a prototype online catalog that
could retrieve information from Internet systems. The prototype
system added information resembling the Gopher document
descriptor to standard MARC records. This is a promising
concept.
As we saw earlier, the Gopher community has already
struggled with the question of how to organize information about
Internet systems, including online catalogs. At the same time,
some libraries have begun adding networked information resources
to their online catalogs, and integrated library system vendors
are providing links to remote systems from online catalogs. It
is only logical to expect that someday we will see a merging of
these two streams of activity. Ideally, the user would interact
with a single user interface that searches for networked
information: the user does not care whether it is a Gopher linked
to an OPAC, or an OPAC linked to a Gopher.
Another alternative client development is a tool for the X
Windows environment called NCSA Mosaic. Written by the National
Center for Supercomputing Applications, Mosaic is a sort of
"super client" that supports connections to a variety of servers:
World-Wide Web, Gopher, USENET News, FTP, and others. Mosaic has
been deployed as a beta release as of this writing. Mosaic
supports numerous document types including various image formats,
audio, and PostScript. Mosaic and similar clients could be an
important advance in networked information, freeing the user from
having to obtain a separate client for each kind of primary
server he or she wants to connect to. Mosaic aspires to provide
the user with a customizable hypertext view of the networked
universe.
+ Page 47 +
Naturally, with its generality, Mosaic presents the user
with considerably more options to consider than does the typical
Gopher client. Moreover, the X platform is used on comparatively
few computers (compared to PCs and Macintoshes), even at
universities. However, this client has generated considerable
enthusiasm among those who have seen it. Besides serving as a
unifying client, Mosaic also provides helpful navigation aids
such as a complete history of where a user has been in her
wanderings through the Internet; it even uses color to highlight
menu items selected earlier in a session. When Mosaic is ported
to more common computing platforms, it could become an important
unified client. NCSA intends to deploy Mosaic on Macintoshes and
perhaps under Microsoft Windows.
Another attempt at a unified client is under development at
the Cornell Law School. A tool called Cello is being developed
for Microsoft Windows.
Not all clients have the straightforward goal of simple
retrieval of documents for the user to read. In May 1992, Steve
Ludtke of Rice University announced a 3-D Gopher client for NeXT
workstations. Dubbed "A Gopher in a Forest," the client presents
a 3-D rendering of IP address space, and it updates the image in
real time as the user moves from server to server or down the
menu hierarchy. This tool generated considerable excitement, but
no one was able to identify a practical use for it. Because IP
address space doesn't correspond to geography, it was not a way
to visualize where in the world documents were coming from, but
it did inspire the idea of a client that could depict a
geographical view of Gopherspace. (Such a client is yet to be
written.)
Perhaps the most exotic alternative Gopher client is the MOO
Gopher. An interactive, multiuser game called Mud--a sort of
network-based Dungeons and Dragons--has been popular on the
Internet for some time now. The Xerox Palo Alto Research Center
has created a variant of Mud called MOO, which provides an
object-oriented language for Mud. MOO is rich enough to support
implementation of a Gopher client, and this has been done. In
some MOO games, the player uses the MOO Gopher to browse the
Internet for answers to questions in order to advance in play.
Opinion is divided as to whether this is of research/educational
value or a waste of time and bandwidth.
+ Page 48 +
18.0 Related Networked Information Server Technologies
Gopher is one of several emerging technologies that help people
to navigate the Internet. It overlaps with the other tools in
two ways: (1) Gopher can serve the same functions as some of the
other technologies, and (2) Gopher can serve as a gateway into
the other services. For instance, a Gopher can offer a menu of
WAIS services. Each pointer to a WAIS server can be presented as
a Gopher index search item.
As a distributed menu system, Gopher is strong in its
support of "resource discovery." Users can browse through a
Gopher and learn about resources available on the Internet they
never dreamed existed. This is an advantage over a tool like
Archie. With Archie, you have to know the file name before you
do your search. When a site "Gopherizes" its FTP service, it
makes the list of files far easier for users to browse.
Like Gopher, HYTELNET is a tool that helps users identify
needed Internet systems. Several years ago, Billy Barron (then
of the University of North Texas) compiled a list of online
catalogs available on the Internet. Building on this list, Peter
Scott of the University of Saskatchewan created HYTELNET, a PC-
based hypertext directory. Over time, the scope of HYTELNET was
expanded to include a wide variety of Internet systems, such as
CWISes. A colleague of Mr. Scott's, Earl Fogel, created UNIX and
VMS versions of HYTELNET that permitted Telnet sessions to
Internet systems. Mr. Scott issues frequent updates about new
Internet systems on a mailing list. By letting users browse
through a list of Internet systems, HYTELNET fills the role of a
resource discovery tool. However, HYTELNET only identifies and
links users to Internet systems; it does not retrieve files or
perform index searches like Gopher.
Another tool, WAIS (Wide Area Information Servers), is a
distributed networked database system. It is based upon an
extension of the NISO Z39.50-1988 standard, which describes a
model for an "originating application" (a client) to query
databases at one or more "targets" (servers). WAIS allows a user
to do keyword searches for documents, scanning a single server or
multiple servers. WAIS responds to a search with a list of
documents sorted by a weighted score--the higher the score, the
better the match to the search. WAIS is strong in its ability to
allow users to sift through a large body of documents stored in
servers across the Internet. It is more appropriate for finding
a small set of documents among a large set of candidates than for
serving as a menuing or browsing tool. WAIS has enjoyed a fair
amount of attention in the general press lately, because its
developers have launched a commercial firm to market it.
+ Page 49 +
Yet another tool, World-Wide Web, evolved in the physics
community, and it is being increasingly recognized as a general
networked information retrieval tool. WWW is a distributed
hypertext system. Information providers can deliver documents
defined in a type of markup language (a subset of the Standard
Generalized Markup Language, SGML, called HTML) that can be
perused by users who need not know the physical location of the
parts of the document they are reading. As a hypertext system,
WWW frees the user from the confines of a rigid hierarchy.
Advocates of WWW claim that this is an essential feature--the
only effective way to deliver documents chosen from a vast
universe of information is via hypertext. They point out that
providing pointers within the text of documents can make it far
easier for users to find and peruse materials of interest. The
WWW model lets users seamlessly cruise from server to server and
from topic to topic. It allows the user to retrace steps as
well. Like Gopher, WWW can launch Telnet sessions to connect to
online services.
WWW can serve as a browsing tool much as Gopher does. Under
Gopher, it is common for a document to include pointers such as
"Look in the 'Campus Eateries' folder for more information." To
follow that advice, the user must leave the current document and
open the folder in question. Under WWW, the pointer text could
highlight "Campus Eateries" within every document where it would
be helpful to mention it; a click on the embedded title would
open the referenced document. Such multiple links are
unobtrusive and do not require the user to hunt through other
folders. It is hard to deny that embedded links are easier for
the user to navigate.
Hypertext services need not require a great deal of
editorial investment. For instance, one site has built a
cross-referenced set of UNIX "man" pages under World Wide-Web.
("Man" pages are brief descriptions of UNIX commands and their
options, one per command.) Every mention of another "man" page
within a document is shown as a link; the user can jump from page
to page at will. This sort of process can be implemented by
means of an automated script, without a great deal of programming
or editorial time required.
+ Page 50 +
These disparate technologies have been exploited at varying
rates. Although numerous subject-specific WAIS databases have
been made available and World-Wide Web has been deployed at quite
a few sites, Gopher seems to be the dominant tool for campus-wide
information systems and for some subject-specific services. In
terms of traffic generated, Gopher is leading the pack. For
instance, counts of packet load on the NSFNET backbone reveal
Gopher is high on the list of network traffic generators (see
Table 3).
-----------------------------------------------------------------
Table 3. NSFNET Backbone Traffic Distribution by Service, March
1993. (Extracted and summarized from
ftp://nic.merit.edu/statistics/nsf-9303.ports)
-----------------------------------------------------------------
Packet Total: 34,874,064,400
Byte Total: 6,502,203,065,800
Service Name Port Packet Count % Pkts Byte Count % Bytes
Gopher 70 327717650 0.940 79023945150 1.215
Z39.50 210 19506350 0.056 5415741150 0.083
WWW 80 11294550 0.032 3613584700 0.056
----------------------------------------------------------------
Gopher has grown dramatically in its ranking in these statistics
over the last several months. Of course, WAIS and WWW are also
growing rapidly as new users come to rely on these tools. To
some extent, these figures overstate Gopher's dominance. For
instance, the use of WAIS to deliver data via Gopher is masked.
Also, since WWW has enjoyed more initial success in Europe, the
use of these U.S. numbers understates its impact somewhat.
Not surprisingly, the relative number of servers deployed
for the major tools shows Gopher with a wide lead as well.
Whereas there are over 1,100 Gopher servers on the Internet,
there are about 118 WAIS servers (supporting over 425 databases)
and about 50 WWW servers. (Of course, these numbers are not
directly comparable. Just as the Library of Congress holds more
books than a small public library, it could be the case that a
given WAIS server holds more data than several Gopher servers.)
+ Page 51 +
Why is Gopher so popular? One reason is the relative ease
with which an information provider can set up a server. As Steve
Worona of Cornell University observes, "Compared to other
Internet navigation tools, a Gopher server is quite easy to set
up. As a result of the low 'entry costs' for setting up a Gopher
service, it has become a very popular tool across the Internet in
a very short time." [9] Another reason is that Gopher clients
have been deployed on the most popular computing platforms--PC
compatibles and Macintoshes. And for those users who lack client
software, Gopher is fully accessible via dial-up and Telnet
paths; WWW, for instance, lacked a good curses client until
recently. (The University of Kansas offers a public curses
client for WWW in support of their CWIS, Lynx.)
The distinctions among these technologies may blur over
time. Groups within the IETF are working to define standards
that will allow an information provider to offer standard
abstract information in order to describe the purpose and content
of a network resource as well as standardized location
descriptions so that users or automated processes can connect to
that resource. For instance, an FTP site could offer
descriptions of all its files, and Archie could allow users to do
keyword searches of those abstracts. Already, the Gopher
developers have announced their intent to support these new
standards. Gopher could thus take on some of the role currently
filled by Archie. The Gopher team have also said they intend to
embrace the Z39.50 standard. As Mark McCahill of the Gopher team
notes, Gopher and other tools may become much more similar with
these enhancements and similar ones.
It is important to bear in mind that these technologies can
interoperate today. Therefore, a site need not use one to the
exclusion of another. For instance, a site might mount a WAIS
database that meets a specific need, while using Gopher as a
campus-wide information system. The Gopher CWIS can include the
WAIS database as a document. In fact, the combination of Gopher
as a CWIS and WAIS as the server for one or more databases is
becoming quite common.
+ Page 52 +
Nor is WAIS the only "back-end" database technology deployed
behind a Gopher "front-end." For example, Tim Howes of the
University of Michigan has implemented a gateway between Gopher
and X.500 directory servers, making it easy for users to browse a
list of X.500 "phone books" from around the world. Similarly,
Ohio State University had an existing telephone directory server
on their campus network; they implemented a gateway from Gopher
to that server rather than building a separate CSO database.
(Some users find CSO telephone searches overly complex compared
to a Gopher index.) Gopher administrators are implementing
databases using a variety of other engines, with Gopher as a
primary or secondary interface to the data. The UNIX Gopher
server also makes it easy for a Gopher administrator to point a
folder to an FTP site or even to a collection of mail messages.
19.0 Gopher's Future
Gopher has existed just about two years, its developers are only
able to work on it part-time, and documentation on how to build a
Gopher service is somewhat spotty. Yet, it has grown into a
production service at dozens of sites around the world. Clearly
it meets a real need--it provides a distributed menu system that
allows users to browse the Internet. Although Gopher faces
competition from rival technologies such as World-Wide Web, its
future seems assured. The Gopher+ protocol promises powerful
extensions to the basic Gopher concept. The Gopher clients and
servers that we will see next year may have significantly greater
capabilities than today's software.
True, Gopher is not unique among Internet technologies in
its ability to deliver networked information. What makes Gopher
special is that it can deliver a browsing list of such documents
and services in a package that's easy to administer and
accessible to users. Via Gopher, users can move from server to
server, quickly seeing what's available and learning about
documents and services they'd never dreamed of. With Veronica
searches, the user can search for documents across multiple
Gopher servers. The user has the choice of browsing or doing a
focused search.
Gopher's most serious competitor is probably the World-Wide
Web. Some critics of WWW point out that there is the threat that
a hypertext service can degenerate into a "twisty maze of
passages all alike" and that users will get lost. WWW advocates
respond that the hierarchical model of a Gopher is mathematically
a subset of the WWW hypertext; an administrator can design a web
to look just like a Gopher hierarchy. (However, a WWW adherent
might ask why an information provider would choose to limit a
service to a hierarchical view.)
+ Page 53 +
As WWW clients become available on more platforms and as
superclients such as Mosaic and Cello are deployed, WWW will
become accessible and attractive to many more users. Tim
Berners-Lee, the main architect of WWW, has s
tated plans to make
it easier to install a WWW server and to "join the Web." With
broader user access and more servers online, WWW could become
more competitive with Gopher. The University of Minnesota and
the Gopher community could face pressure to provide hypertext
support within Gopher. The question is whether Gopher can retain
its ease of setup and use if it embraces hypertext.
Gopher/WWW interoperation is already common. The UNIX
Gopher server can offer a Gopher hierarchy to the Web. The
developers of Mosaic and NCSA have stated their intent to deliver
a unified Gopher/WWW server that is capable of serving a Gopher
hierarchy directly to WWW clients. These developments could
encourage merging of the tools. The Internet Engineering Task
Force has formed a working group that is looking at integration
of resource discovery tools such as Gopher and WWW.
Recent statements from the University of Minnesota indicate
that, if Gopher is used for commercial purposes, such use will
require a license agreement. The University of Minnesota intends
to continue to make Gopher available free of charge for nonprofit
academic use. Much of the development of Gopher has been
possible because of the keen interest of a supportive community.
Will that community continue to contribute to a corpus for
someone else's financial benefit? Already the announcement of
licensing fees has spurred one site to offer a free Gopher server
implemented in a few hundred lines of code (written in Perl).
Another site is offering a "GNU Gopher" server. (The GNU project
is a movement dedicated to providing free versions of UNIX and
related tools.) Note that related tools have also "gone
commercial" recently. This is the case with Archie, now to be
developed by Bunyip Information Systems, and WAIS, to be enhanced
and marketed by a private company. (Note that as of this writing
WWW is offered under similar terms to the new Gopher license;
commercial users are expected to contribute development effort or
pay a fee.) It will be interesting to watch the effect of
commercialization on all of these products.
+ Page 54 +
For the present, Gopher enjoys overwhelmingly superior
market penetration compared to competitive tools. It is
impossible to gauge the impact of all the economic and technical
developments in the Gopher community and in the networked
information field at large. Over the long run, Gopher might
remain a dominant player, or it might merge with another
technology. It is a safe bet that it will be an important tool
for the next several years at least. In the short run, no single
networked information retrieval scheme will meet all of the needs
of the fast-growing body of Internet users.
Notes
1. Steve Worona, personal e-mail message, 25 February 1993.
2. Billy Barron, personal e-mail message, 10 March 1993.
3. Marty Courtois, personal e-mail message, 26 February 1993.
4. Ibid.
5. Marie-Christine Mahe, personal e-mail message, 9 March 1993.
6. Nancy John, personal e-mail message, 2 March 1993.
7. Joel Cooper, personal e-mail message, 1 March 1993.
8. Martin Dillon, personal e-mail message, 9 March 1993.
9. Steve Worona, personal e-mail message, 25 February 1993.
Bibliography
Deutsch, Peter. "Resource Discovery in an Internet Environment--
The Archie Approach." Electronic Networking: Research,
Applications and Policy 2, no. 1 (1992): 45-51.
Berners-Lee, Tim et al. "World-Wide Web: The Information
Universe." Electronic Networking: Research, Applications and
Policy 2, no. 1 (1992): 52-58.
Kahle, Brewster et al. "Wide Area Information Servers: An
Executive Information System for Unstructured Files." Electronic
Networking: Research, Applications and Policy 2, no. 1 (1992):
59-68.
Lynch, Clifford A. "Information Retrieval as a Network
Application." Library Hi Tech 8, no. 4 (1990): 57-72.
+ Page 55 +
Scott, Peter. "Using HYTELNET to Access Internet Resources."
The Public-Access Computer Systems Review 3, no. 4 (1992): 15-21.
To retrieve this file, send the following e-mail message to
LISTSERV@UHUPVM1.UH.EDU: GET SCOTT PRV3N4 F=MAIL.
Glossary
Anonymous FTP. Anonymous FTP servers allow users to retrieve
files without the need for assigned user IDs (literally the word
"anonymous" is used as the login ID). This service is offered by
many sites on the Internet.
Archie. A network service that allows users to discover which
anonymous FTP sites house particular files of interest.
Developed at McGill University (and now Bunyip Information
Systems), future versions of Archie may allow searching for
resources by abstract, author name, and other criteria.
ASCII file. A file encoded in the 128-character ASCII (American
Standard Code for Information Interchange) character set. The
term "flat ASCII file" is often used to refer to a simple text
file, with no embedded special formatting codes or binary data.
In FTP transfers, "text" and "ASCII" are synonymous.
Binary file. Binary files consist of streams of bytes whose
meaning is defined by some external format standard. For
example, executable computer programs are binary files. In FTP
transfers, a binary file is specified by "bin" or "image"
settings.
Client/Server. A model for distributing system functions between
client software, residing on a user's workstation, and server
software, residing on a host. The host could be a UNIX
workstation, a mainframe, or another type of computer. The
client handles most of the information presentation functions,
and the server handles most of the database functions. A
protocol specifies how the two should communicate. The
client/server model is growing in popularity as workstations and
networks grow in power.
CWIS (Campus-Wide Information System). A university or college
information system that offers integrated access to documents
(e.g., course schedules, lists of current events, and academic
job openings) and systems (e.g., online catalog). CWISes began
on mainframes and are now commonly implemented under the
client/server model. Gopher and WWW are commonly used for
CWISes; other CWISes exist (for instance, the TechInfo software
from MIT).
+ Page 56 +
CSO. A protocol that allows client/server searching of simple
databases such as phone books. Named after the Computing
Services Organization at the University of Illinois, the CSO
protocol enjoys widespread usage in the Gopher community, despite
more elaborate standards for such "white pages" services.
(Sometimes called "CCSO.")
Curses. A software feature under UNIX that allows a programmer
to support full-screen terminal sessions. Said to be a play on
words referring to the cursor keys.
FAQ (Frequently Asked Question). Documents that list such
questions and their answers are referred to as FAQs. Much of the
documentation in the USENET world resides in FAQ files.
FTP (File Transfer Protocol). A standard protocol for sending
files from one computer to another on TCP/IP networks, such as
the Internet. This is also the command the user usually types to
start an FTP session.
GIF (Graphics Interchange Format). A still-image file format
promoted by CompuServe. Software to view GIF images is commonly
available for most computing environments in the form of public
domain, shareware, or commercial products.
GNU. A project to deliver UNIX operating system clones and
related tools as freely available software. (Stands for "GNU is
Not UNIX.")
Hypertext. A scheme for supporting embedded links within
documents. While browsing a document with hypertext links, a
user can select one of those links and quickly move to the
document it points to. Popularized by the HyperCard Macintosh
program.
HYTELNET. A hypertext database of Internet systems, such as
online catalogs and CWISes. The PC version of the program is
available from Peter Scott at the University of Saskatchewan.
The UNIX and VMS versions can make Internet connections to listed
systems; the PC version cannot.
IANA (Internet Assigned Numbers Authority). Internet protocol
writers must agree upon standard values for fields used within
the protocols. IANA is the organization that registers these
standard numbers. For instance, IANA assigned TCP port 70 to
Gopher. IANA will register MIME content types.
+ Page 57 +
IETF (Internet Engineering Task Force). IETF devises new and
updated protocols to be used on the Internet. It is an informal
body composed of Working Groups that carry on discussions over
the Internet and in periodic meetings.
IP address. A unique number assigned to a computer on a TCP/IP
network. Conventions have been set up to assign IP numbers in a
systematic fashion across the Internet. Whether a machine is a
large server or a small PC, if it is to be on the Internet, it
must have an assigned IP address. IP addresses look like
"35.8.2.61." There are always four numeric values, separated by
periods, in IP addresses.
JPEG (Joint Photographic Experts Group). A still-image file
format that allows efficient compression. The JPEG compression
scheme is "lossy"; it does not preserve all of the data, but it
can yield significant space savings with little perceptible loss.
JPEG viewers are relatively slow compared to GIF viewers.
MIME (Multipurpose Internet Mail Extensions). Initially, an
extension of Internet mail standards to allow binary data to be
embedded in SMTP mail. Since its introduction in 1992, MIME has
been implemented on several computer platforms (often under the
name "Metamail"), and it is increasingly viewed as the
appropriate standard for handling multimedia information to be
moved across dissimilar computing environments, whether sent via
e-mail or otherwise.
Mosaic. An integrated client program developed by the National
Center for Supercomputing Applications. Mosaic acts as a client
for multiple Internet services, including Gopher, WAIS, WWW,
USENET News, and FTP. Currently implemented on UNIX systems
supporting X Windows and Motif. Versions of Mosaic for the
Macintosh and Microsoft Windows are expected.
PostScript. A printer description language from Adobe.
PostScript is the dominant format used for desktop publishing.
Documents in PostScript format are commonly shared across the
Internet and printed on laser printers after retrieval from a
remote archive.
+ Page 58 +
PPP (Point-to-Point Protocol). A relatively new protocol that
allows dial-up users to connect to the Internet. With PPP (or
similar functionality) a user can use Internet client software,
such as a Gopher client, in a dial-up session. Without PPP, the
user must dial into a host or public client service via a
terminal session (usually VT 100).
RFC (Request for Comments). Documents that define both proposed
and adopted Internet protocol standards. RFCs are numbered in an
ordinal fashion.
SGML (Standard Generalized Markup Language). SGML is a scheme
(and an ISO standard) for embedding structural information within
a document. SGML is popular in scholarly and electronic
publishing as a way to support multiple views of a document. An
SGML-compliant set of structures called HTML is used by World-
Wide Web.
SLIP (Serial Line IP). A protocol that allows dial-up users to
connect to the Internet. Being supplanted by PPP.
SMTP (Simple Mail Transfer Protocol). A protocol for sending e-
mail messages between computers on TCP/IP networks, such as the
Internet. The user does not run a program named SMTP; instead,
various e-mail packages know how to utilize this protocol.
TCP/IP (Transmission Control Protocol/Internet Protocol).
Technically, TCP and IP are separate protocols; together they
allow computers on the Internet to communicate by providing a
reliable way for bytes to be delivered in order over a network
connection. Connections are made to TCP "ports," allowing
multiple connections per machine. A port is described by a
number (e.g., Gopher servers typically use port 70).
Telnet. The TCP/IP protocol for remote terminal sessions.
Usually implemented as a command of the same name.
TN3270. A variant of Telnet that allows TCP/IP connections to
IBM mainframes that utilize 3270 terminal conventions.
Uniform Resource Identifier. An umbrella term for standards that
describe Internet resources in a uniform way. The IETF is
considering a Uniform Resource Locator, which will a standard way
to name a particular document on a particular network server.
Another proposed standard, the Uniform Resource Number, will be a
unique number (analogous to an ISBN) assigned to a document or
resource regardless of its location and other resource
descriptors.
+ Page 59 +
USENET News. A distributed discussion list system, much of whose
traffic is carried over the Internet. USENET News services
consist of news "feeds" typically provided by one or more servers
on a campus network, and news "readers" (i.e., client software
that communicates with the server over a news delivery protocol).
Veronica. A service that provides a Internet-wide index of
Gopher document titles. Developed at the University of Nevada,
Veronica servers periodically poll all the Gopher servers they
can connect to and build a title index that can, in turn, be
pointed to as a standard Gopher index.
VT 100. The dominant communications protocol for full-screen
terminal sessions. The VT 100 standard was defined by the
Digital Equipment Corporation in the 70s. Most terminal
emulation software packages (e.g., Kermit and PROCOMM) implement
VT 100 or its descendants.
WAIS (Wide Area Information Servers). Based on an extension the
Z39.50-1988 standard, WAIS allows searches of documents on one or
more WAIS servers. Originally promulgated by Thinking Machines
Corporation, WAIS is now offered in a commercial version (by
WAIS, Inc.) and a public domain version (by the Clearinghouse for
Networked Information Discovery and Retrieval). The WAIS search
engine is commonly used by Gopher servers. An index document
under the UNIX Gopher server can point to a stand-alone WAIS
server.
World-Wide Web. A network-based hypertext document delivery
system. Developed at CERN in Switzerland, WWW is growing in
popularity. WWW supports embedded links to documents.
Z39.50. A NISO standard defining a client/server model for
searching bibliographic and other databases.
Z39.58. A NISO standard describing a Common Command Language for
online catalogs.
+ Page 60 +
Note From the Author
After this document has been distributed via The Public-Access
Computer Systems Review, it will be made available on the central
Gopher at Michigan State University (gopher.msu.edu, port 70).
It will be placed under the "More About Gopher" folder.
About the Author
Rich Wiggins, Gopher Coordinator, Michigan State University
Computer Laboratory. Voice: (517) 353-4955. Internet:
RWWMAINT@MSU.EDU.
-----------------------------------------------------------------
The Public-Access Computer Systems Review is an electronic
journal that is distributed on BITNET, Internet, and other
computer networks. There is no subscription fee.
To subscribe, send an e-mail message to LISTSERV@UHUPVM1
(BITNET) or LISTSERV@UHUPVM1.UH.EDU (Internet) that says:
SUBSCRIBE PACS-P First Name Last Name. PACS-P subscribers also
receive two electronic newsletters: Current Cites and Public-
Access Computer Systems News.
This article is Copyright (C) 1993 by Rich Wiggins. All
Rights Reserved.
The Public-Access Computer Systems Review is Copyright (C)
1993 by the University Libraries, University of Houston. All
Rights Reserved.
Copying is permitted for noncommercial use by academic
computer centers, computer conferences, individual scholars, and
libraries. Libraries are authorized to add the journal to their
collection, in electronic or printed form, at no charge. This
message must appear on all copied material. All commercial use
requires permission.
-----------------------------------------------------------------
