From: gopher@boombox.micro.umn.edu ("The Gopher Team" )
Newsgroups: alt.gopher
Subject: Gopher Phase II Wish-List Compilation
Date: 24 Jul 92 18:25:17 GMT
Distribution: alt
Original-To: gopher-news@boombox.micro.umn.edu

This is being written to put rumors, fears, injured egos, and
alt.gopher flames to rest.

Yes, internet Gopher originated from the University of Minnesota.
Yes, enormous amounts of invaluable contributions from other folks on
the Internet have changed its look and capabilities from a campus-wide
information system to an Internet-wide document search and retrieval
system.  And yes, this growth and change has been evolutionary and
somewhat disorderly (as evolution often is).

While the original Gopher Team does maintain an archive site for
convenient distribution of all the gopher software, mods, and tools,
and while we'll continue to incorporate enhancements designed here and
elsewhere, we're not a Standards Committee.  Our small size and
relative freedom to move allows us to get things done quickly, and we
value that.  Gopher was put together with a handful of guiding
principles, and we try to view changes in the light of those
principles.  To recap the basic ideas:

+  Keep the protocol connectionless (one request/one response per transaction)
+  Keep intelligence in the server.  Keep the protocol simple.
+  Keep requests and responses (directory ones at any rate!) to readable text.
+  Be able to debug clients and servers using telnet.
+  Make the client-writer's job as simple as possible 
   (client writer's real job is the user interface).
+  Clients must run efficiently on Macs and PCs, (the world is not just UNIX).
+  Information producers should run their own server (Mac, PC, UNIX box) rather
   than rely on the "computer center" to maintain their data for them.

And so, things we'd like to avoid:

- Complex back-and-forth option or feature negotiations between 
  client and server.

- Proliferation of document/resource types that are platform-specific. 
  Excessive proliferation of types makes it harder to write a good client.

- Breaking compatibility with old clients and servers.

Finally, here is the most requested and needed wish-list for the Future of 
Gopher (in no particular order):

1.  Retrieval (and perhaps display) of documents other than text
    (pictures, sounds, binaries, smells)

2.  Encoding an access method (eg. gopher, ftp, wais, etc.) and an
    ident in a gopher list (directory) item. 

3.  Generic index servers (for UNIX, Mac, PC) that allow incremental 
    update.

4.  A gopherspace cruiser daemon that, coupled with #3 could be used
    for autoindexing at least all doc names in some subspace... a sort of
    Archie for gopherspace.

5.  More formal process for enhancements (Oh no! Not that :-))

6.  Primary server organization questions and conventions.

7.  Mechanism for identifying and contacting the administrator of a server.

8.  ID and password to allow controlled access to a document.

9.  A "put this document on the server" facility.  Note: This is
    pretty contrary to the basic Gopher philosophy: "You got data?  Run a
    server off your desk."

10. Generic "prompt user, get input, feed it to a server-based
    process, return output to the user" facility.  Note that this will
    subsume #8 and #9 above.  It could be used for password protected
    stuff, ftp, submitting documents, etc.

11. A push for easier resource discovery, server communication (called
    by various names).  Perhaps simple, static-list based global indexing
    of document names on "all" gopher servers.  Note: This must wait for a
    good #3 & #4; we're working on that.

12. Single efficent data transfer method.  Probably a headed table
    (length count + data block)

13. Alternative representations of document types while preserving the
    lowest common denominator: TEXT.


 - The Gopher Team.
Newsgroups: alt.gopher