Rob.Harper at fi.csc
Tue Aug 18 01:24:55 EST 1992
Just in case you missed it here is the latest info regarding development
of the gopher software.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%% CLIP %%%%%%%%%%%%%%%%%%%%%%%%%%%%
GopherCon '92: Trip report
riddle at rice.edu
SUMMARY: GopherCon '92 was a small working session of
Gopher developers and users. Focuses included proposed
extensions to the Gopher protocol; how to organize the
Internet resources available through Gopher in a more
usable fashion; Gopher server administration, including
security and privacy issues; and the future of Gopher
development. Also announced at the conference was a
special offer of NeXT hardware for use as Gopher servers.
BACKGROUND: GopherCon '92 took place on August 12th and 13th in Ann
Arbor, Michigan and was sponsored by CICnet, a regional network in the
Great Lakes/Midwest area. It was attended by about 50 people (despite
an advertised cap of 30) including Gopher developers, CWIS
administrators, systems programmers, user consultants, and a number of
librarians. Almost all were employed by universities or regional
OVERVIEW BY THE GOPHER DEVELOPERS: The conference began with an
overview by Mark McCahill and Farhad Anklesaria, two members of the
Gopher Team at Minnesota. I liked their summary of the two initial
goals for Gopher:
-- To provide the plumbing for a great CWIS.
-- To be "Internet duct tape" for connecting a wide variety of
Although many of us at the conference tended to be driven by the demand
for one or the other of these, ultimately they go together nicely.
GOPHER+: The Monday before the conference the GopherTeam at UMinn had
distributed to the attendees an announcement of a set of proposed
enhancements to the internet Gopher protocol, called Gopher+. A
revised Gopher+ proposal has been announced to comp.infosystems.gopher
(ftpable from boombox.micro.umn.edu:/pub/gopher/gopher_protocol/Gopher+)
so I don't want to dwell on the details, but Gopher+ is intended
to add some of the things the Gopher community has been calling for:
mechanisms for identifying and contacting data providers and
maintainers, mechanisms for returning more information from the client
to the server, and alternative representations of document types (e.g.
text vs. PostScript). Gopher+ will be backward-compatible with old
Gopher: old Gopher clients and servers either do now or can easily be
modified to ignore extra information in the Gopher+ protocol, and
Gopher+ clients and servers will continue to work when pointed at old
Gopher servers. In the words of McCahill & Anklesaria, "Gopher+ is
Gopher with a bag taped to the side to hold more".
Gopher+ raises two broad categories of doubt in the minds of many of
us, which were discussed in almost every session at the conference:
complexity and security. Will Gopher+ become so complex that client
and server software become impractical to write, especially on low-end
platforms? ("Will the bag on the side become bigger than the
Gopher?") This will only become clear when the Gopher Team at UMinn
writes some working code. The security issues, on the other hand, were
pretty well resolved in extensive discussion (see below). Overall I
think we all left the conference feeling optimistic about Gopher+ and
happy with the backward-compatible development path proposed by the
RELATED TECHNOLOGIES: Ed Vielmetti of CICnet gave a talk on "what we
would be gathering to discuss if UMinn had never developed Gopher",
meaning primarily World-Wide Web (WWW). WWW was developed for the
high-energy physics community and serves as a model of what Gopher
could do if a discipline-oriented virtual community invested in it
heavily. WWW is based on SGML (Standard General Markup Language"), an
ISO standard for marking up text which WWW uses to implement
hypertext. SGML is a bear and it is a significant investment of effort
to properly add a document to WWW, but the result is quite powerful
(for instance, WWW handles footnotes in hypertext). The usefulness of
a markup language of some kind for Gopher came up repeatedly,
particularly to solve the "large text" problem (a good use of a markup
language could allow a client to ask for successive chunks of a large
document rather than the whole thing at once). It was pointed out that
WWW servers can point at Gopherspace, and the possibility of using
Gopher to point at WWWspace was discussed (by presenting an SGML
document as a Gopher directory, in which text and hypertext references
would appear as separate items). Finally, the relative numeric success
of Gopher over WWW was discussed (there are orders of magnitude more
Gopher servers than WWW servers out there): Gopher seems to have won
out primarily because of the ease of entry (it's much harder to put up
a WWW server than a Gopher server), although another factor may be that
a hierarchical presentation is more appropriate than hypertext for the
broad-based audience of a CWIS.
PROTOCOL EXTENSIONS: The Gopher Team had already spoken about their
proposals for Gopher+, so this was a chance for others in the Gopher
community to air their own wish lists and local modifications to
Fred Crowner and Clifford Collins of Ohio State talked about a lot of
human factors work they had done on their CWIS, primarily through
enhancements of the Gopher curses client: variable 1- column or
2-column format, depending on number of items; help by item, rather
than a single help context; "go words" so users can learn commands
which allow them to jump directly to commonly used items; mail input by
the user ("Ask-a-Programmer", "Ask-a- Purchasing-Agent", etc.);
"chunking" of very large documents (e.g. course catalogs), which proved
to be a serious hairball and which they would now implement differently
(probably by breaking a large document into numerous small ones and
indexing them). They also put work into making the client more secure
for unauthenticated users.
Andrew Gilmartin of Brown University added a lot of information to the
Unix Gopher's link files: author, provider (not the author but the
person who gave the information to the CWIS administrator),
administrator, expiration, creation and modification dates, keywords,
and index type (full, keyword, none, or all). This closely paralleled
the proposals for "attributes" in the Gopher+ protocol. There ensued
some lively debate about the meaning and necessity of several of these
attributes, with the librarians particularly emphatic about the
necessity of maintaining detailed information about the origin of a
document. This underscored the necessity of fully defining the
semantics of important Gopher+ attributes in advance, so clients and
servers can be written which agree on how to use them.
Lee Brintle from the University of Iowa's "panda" project talked about
some of their extensive modifications to Gopher: printer selection,
remote updating of files by data maintainers, scripting (a forth-based
interpreter in the client to allow massaging of input to and output
from complex servers such as the geography server), grep-like
searching of non-WAISified data, and search by title on the current
level (a la rn and elm). Panda has evolved into an entirely different
animal from Gopher (for starters, it is written in C++) and it is not
clear which of these enhancements may make it back to the mainstream.
The one Panda feature which seemed to gain everyone's approval was the
ability to put explanatory text at the top and/or bottom of the screen
rather than in an "About" file.
RESOURCE DISCOVERY AND NAVIGATION: Or, as librarian Nancy John of the
University of Illinois at Chicago put it, "collections development,
cataloging and filing." :-) There has been much discussion in
Gopherland at large of how to develop an index of resources in
Gopherspace, which would then be served out by Archie. Billy Barron of
the University of North Texas summarized two competing approaches:
-- "ls -lR", e.g., automated recursive search of all of
Gopherspace: this is easy and gets you everything in Gopherspace,
but the quailty of information is low.
-- Registration: authoritative sites for a particular resource
would register the resource, either by putting a "LocalResources"
directory out in Gopherspace or by use of a standard "IAFA
template" (this could become an "IAFA attribute" in Gopher+).
This is more work than the "ls -lR" approach, does not get you
everything, but the quality is high.
Billy Barron favors using both approaches and somehow signaling the
difference to the user.
Tim Howes of the University of Michigan talked about his Gopher to
X.500 gateway, "
More information about the Bio-soft