:READ GOPHER23 README A1 GOPHER 10/15/92 10:09:53 I guess I'm at least as bad as anyone else about documentation. There are comments in the sample files. Work is progressing on "real" documentation. This package, including both client (GOPHERC) and server (GOPHERD) is available in several forms, any one of which contains all you need: GOPHER23 CARDDUMP -- Cornell 'CARD' format GOPHER23 TAR -- Rice CMS TAR format (UNIX 'tar' compatible) GOPHER23 READCARD -- punch it to yourself and run READCARD GOPHER23 PACKAGE -- available via LISTSERV Except! that the READCARD deck does not contain executable MODULEs. ------ ------ ------ ------ ------ ------ ------ ------ ------ Setting up the client (user end): Really there's not much to it. Just have GOPHER EXEC on an ACCESSed disk and the rest of the package on some other, or the same, disk. GOPHER EXEC is site-tailorable and calls GOPHERC EXEC, the real code. Here at Rice, we put most applications on their own minidisk (makes maintenance easier, for us anyway), and our GOPHER EXEC checks for the existence of GOPHERC EXEC and does a LINK and ACCESS of the right product disk(s) iff needed. Setting up the server: CMS Gopher server "directories" are defined by FILELIST files. FILELISTs within FILELISTs define sub-directories. The "root" is typically FILELIST, where is the VM userid of the server virtual machine, usually GOPHERD. Everything after the filemode (third word, presently ignored, BTW) is considered a "relative path" and concatenated onto the end of the path to the directory (FILELIST) which lists the file. This path is the "name" that the client displays, unless the name is overridden in a NAMES file (or if the file is a GOPHER (link) file). The filename (first word) must be preceeded by at least one blank space in the FILELIST. An asterisk in column one defines a comment in the FILELIST. (just like a standard CMS FILELIST, so you can in fact use a Gopher FILELIST as input to CMS' FILELIST EXEC) A GOPHER file (filetype GOPHER) is a "link" to another Gopher server. The contents of a GOPHER (link) file are the same as for a UNIX Gopher link file, of the form: name=Rice University CMS Gopher server host=RICEVM1.RICE.EDU port=70 path=1/ type=1 A NAMES file may accompany any FILELIST file, providing overrides to the default "type" and "name" values sent to the client(s). The NAMES file is also where pipeline specifications are defined, if any, for each file. ------ ------ ------ ------ ------ ------ ------ ------ ------ There is a discussion list, VMGOPHER@PUCC.Princeton.EDU. There is another CMS Gopher (both server and client), sometimes called "the Vienna Gopher", available from Gerhard Gonter . From: WTS@MAINE.MAINE.EDU (Wayne Smith) The basics, documents and FILELIST menus, is fairly easy to grasp, but the relationship of a NAMES file and its entries to a FILELIST file and its entries is not at all evident to the poor soul that just wants to provide an information service without much time invested (I.e., without subscribing to VMGOPHER). A: The easiest way to start is just name some plain-text files in GOPHERD FILELIST (which are available to your GOPHERD service machine on an accessed disk or SFS directory). Then try some "links" (filetype GOPHER) and sub-menus (filetype FILELIST). Then try some overrides (with a NAMES file for the FILELIST to be overridden). It has been suggested that the whole thing be consolidated: from FILELIST/GOPHER/NAMES, just have NAMES files. In the long run, this will probably work. It's almost possible now, but still, many may find FILELISTs easier to understand. Q: How to I point to another server/menu? A: The easiest way is with a "link" file (filetype GOPHER). When a link file shows-up in any FILELIST, the contents of that file are read and the information specified is presented to the client for that particular menu item. Q: How does a GOPHER file differ from a "link" in a NAMES file? A: The NAMES file is far more extensive. With CMS GopherD, you don't use "link" files to override the characteristics of other files in the menu (as you would with a UNIX server). With CMS GopherD, GOPHER (link) files are exclusively used to reference other network (usually non-local) resources, while the NAMES file may apply to files which reside on your system and/or "links" or remote services which are mearly listed locally. Q: Some folks have made it seem that their GOPHER server files are free for the taking ... is there a GOPHER feature to pull these in? A: To "receive" an item, press PF5. The receive function will not overwrite an existing file (though you can still view & SAVE from XEDIT). Q: GOPHERD should document DISKWRIT in the prolog. A: GOPHERD uses DISKWRIT to perform the same "reaccess" trick GONE EXEC does when you reconnect. If disks appear to have changed, they are reACCESSed so that GopherD has the latest revision of any files on said minidisks. Q: Why are the "STANDARD" translate-table files provided? Are these for use with the server? A: The default ASCII<--->EBCDIC translation in VM TCP/IP (FAL) is not 100% correct for the majority of the VM/UNIX/VMS/DOS/Mac world we live in. STANDARD TCPXLATE and TCPXLBIN provide a 1-for-1 translation between de-facto "network EBCDIC" (codepage 1047) and "extended ASCII" (ISO 8859-1). Q: If PhoneBk and Search are available, how do we use them? A: Presently, CMS GopherD does not support PhoneBk and Search engines. The client (GOPHERC) is happy to utilize such servers on other hosts. Q: Some GOPHERs restrict access or output to some clients; how? A: Specify an "auth" value in the NAMES file. The tag :auth. allows for control over any object in a menu (defined by a FILELIST and/or NAMES file), even the menu itself. Q: Is there anything different about your RXSOCKET? A: RXSOCKET was created by Arty Ecock. He maintains it. Rice doesn't have any mods to RXSOCKET, and Gopher doesn't need any special treatment from RXSOCKET. If you find an RXSOCKET packaged with CMS Gopher to be out-of-date, by all means, use the current one or get the latest from Arty. If you pick-up RXSOCKET MODULE from a UNIX FTP host, you must "deblock" it back into its CMS form (record oriented) with: PIPE DISK RXSOCKET U-MODULE | DEBLOCK CMS | DISK RXSOCKET MODULE ------ ------ ------ ------ ------ ------ ------ ------ ------ Thanks to: Yossie Silverman, Jim Gerland, Arty Ecock, Serge Goldstein, Chuck Boeheim, Wayne Smith, Jim Colten, Nick LaFlamme, ... (this list continues to grow, and some have surely been left out) ------ ------ ------ ------ ------ ------ ------ ------ ------ Files associated with CMS Gopher 2.3: GOPHER23 FILELIST GOPHER23 NAMES GOPHER23 README (this file) client: GOPHER EXEC GOPHERC EXEC GOPHERC REXX GVM EXEC GVM DIRECT server: GOPHERD EXEC GOPHERD REXX GOPHERDM REXX GOPHERDS REXX GOPHERD DIRECT support: EXPAND REXX (expands tabs in plain text files) DROPDOTS REXX (removes trailing . lines from plain text) PRINT REXX (works kinda like regular CMS PRINT) A2E REXX (ASCII to EBCDIC translation) E2A REXX (EBCDIC to ASCII translation) TCPA2E REXX (ASCII to EBCDIC translation) TCPE2A REXX (EBCDIC to ASCII translation) STANDARD TCPXLATE (translate table in source form) STANDARD TCPXLBIN (translate table in object form) support modules: RXSOCKET MODULE (TCP/IP socket interface to REXX EXECs) DISKWRIT MODULE (tells if a R/O minidisk has been changed) _REFRESH EXEC (reACCESSes changed R/O minidisks) a tool for browsing Gopher FILELISTs directly: GL EXEC help files: GOPHER HELPCMS BROWSER HELPGOPHER VIEW HELPGOPHER FIND HELPGOPHER LOOKUP HELPGOPHER SEARCH HELPGOPHER BOOKMARK HELPGOPHER BOOKLIST HELPGOP