Welcome to comp.infosystems.gopher
ed vielmetti
went
out fifteen years ago, and the newsgroup is still around, so we might
as well use it.
gopher is a distributed information system. The best phrase I've
heard to
describe it is as "internet duct tape" - wrap a little bit of gopher
protocol around some files or some databases and hey presto you have
an
Internet Service. As most people know information services on the
internet are traditionally held together with spit and bailing wire,
well,
duct tape is an improvement.
The newsgroup basically covers four areas of gopher development, which
I'd
list as
gopher clients. Things that users run to connect to gopher servers.
There are lots of these out there right now; most of them follow
pretty
closely in spirit to the original unix and mac gopher clients, though
some
radical ones ("gopher in a forest" for NeXT) push a different
approach.
The issues here are design, documentation and built-in help, bug fixes
and
improvements, human factors analysis, speed, robustness, and such.
There a gopher clients baked into web browsers, and some of them have
issues.
gopher servers. Systems that speak the gopher protocol. There are
rather
less server designs than client designs; most servers present
essentially
a file system point of view to the user, though some are driven from
databases. A number of other data resources have been gatewayed into
gopher (e.g. weather, Twitter) with interesting results. The issues
here are
maintainability, shared resources access, logging and stats gathering,
index and other wayfinding aids, etc.
gopher protocol. What clients and servers send back and forth to each
other. The gopher protocol is a ferociously simple ASCII protocol
designed to make constructing clients and servers in an afternoon
possible
and even likely. Various extensions to the base protocol have been
proposed to handle more client features, with varying degrees of
acceptance. Issues here are staying close to the One True Gopher Way
with simple clients and servers without stopping people who want to do
way
cool advanced things from working together.
gopherspace engineering. This is a problem completely separate from
any
sort of technical issues; it's a question of how gopherspace should be
designed, what it feels like, who has control, how easy is it to move
around, what kind of cooperative systems-building can we end up with.
The
questions here are those of groupware and computer-supported
collaborative
work, human factors and information systems design, resource discovery
and
current awareness tools, and so on. Even if we end up throwing away
the
protocol and all of the clients the question of systems design (for
the
Internet, I suppose, and not just gopherspace) is a big one.
300+ people voted for the new group 15 years ago. I'm going to ask
some of
the people who have built systems using gopher to speak up and say
their
piece about current and past projects and try to figure out where we
go from here.
Edward Vielmetti, Ann Arbor MI 48104 e...@monkey.org
"As of GopherCon '92, Ed Vielmetti was talking about how Gopher had
basically surpassed WWW in common usage." Six Apart Blog
Edward Vielmetti
have wider line lengths, and the Google news posting
client munched it.
Ed
"Usenet is a right, a left, a jab, and a sharp uppercut
to the jaw. The postman hits! You have new mail."