RFC 1436                         Gopher                       March 1993


3.7.2  Building full-text search servers

   A full-text search server is a special-purpose server that knows
   about the Gopher scheme for retrieving documents.  These servers
   maintain a full-text index of the contents of plain text documents on
   Gopher servers in some specified domain.  A Gopher full-text search
   server was implemented using several NeXTstations because it was easy
   to take advantage of the full-text index/search engine built into the
   NeXT system software.  A search server for generic UNIX systems based
   on the public domain WAIS search engine, is also available and
   currently an optional part of the UNIX gopher server.  In addition,
   at least one implementation of the gopher server incorperates a
   gateway to WAIS servers by presenting the WAIS servers to gopherspace
   as full-text search servers.  The gopher<->WAIS gateway servers does
   the work of translating from gopher protocol to WAIS so unmodified
   gopher clients can access WAIS servers via the gateway server.

   By using several index servers (rather than a monolithic index
   server) indexes may be searched in parallel (although the client
   software is not aware of this).  While maintaining full-text indexes
   of documents distributed over many machines may seem a daunting task,
   the task can be broken into smaller pieces (update only a portion of
   the indexes, search several partial indexes in parallel) so that it
   is manageable.  By spreading this task over several small, cheap (and
   fast) workstations it is possible to take advantage of fine-grain
   parallelism.  Again, the client software is not aware of this. Client
   software only needs to know that it can send a search string to an
   index server and will receive a list of documents that contain the
   words in the search string.

3.8  Item type characters

   The client software decides what items are available by looking at
   the first character of each line in a directory listing.  Augmenting
   this list can extend the protocol.  A list of defined item-type
   characters follows:

   0   Item is a file
   1   Item is a directory
   2   Item is a CSO phone-book server
   3   Error
   4   Item is a BinHexed Macintosh file.
   5   Item is DOS binary archive of some sort.
       Client must read until the TCP connection closes.  Beware.
   6   Item is a UNIX uuencoded file.
   7   Item is an Index-Search server.
   8   Item points to a text-based telnet session.
   9   Item is a binary file!




 
RFC 1436                         Gopher                       March 1993


       Client must read until the TCP connection closes.  Beware.
   +   Item is a redundant server
   T   Item points to a text-based tn3270 session.
   g   Item is a GIF format graphics file.
   I   Item is some kind of image file.  Client decides how to display.

   Characters '0' through 'Z' are reserved.  Local experiments should
   use other characters.  Machine-specific extensions are not
   encouraged.  Note that for type 5 or type 9 the client must be
   prepared to read until the connection closes.  There will be no
   period at the end of the file; the contents of these files are binary
   and the client must decide what to do with them based perhaps on the
   .xxx extension.

3.9  User display strings and server selector strings

   User display strings are intended to be displayed on a line on a
   typical screen for a user's viewing pleasure.  While many screens can
   accommodate 80 character lines, some space is needed to display a tag
   of some sort to tell the user what sort of item this is.  Because of
   this, the user display string should be kept under 70 characters in
   length.  Clients may truncate to a length convenient to them.

4.   Simplicity is intentional

   As far as possible we desire any new features to be carried as new
   protocols that will be hidden behind new document-types.  The
   internet Gopher philosophy is:

      (a) Intelligence is held by the server.  Clients have the option
      of being able to access new document types (different, other types
      of servers) by simply recognizing the document-type character.
      Further intelligence to be borne by the protocol should be
      minimized.