HDTenEightyP/NetNews huggingface dataset:
From: guido@cwi.nl (Guido van Rossum)
Newsgroups: comp.infosystems.gopher
Subject: Re: MIME in Gopher (was Re: Gopher+ Considered Harmful)
Date: 12 Dec 92 12:03:07 GMT

Dan Connolly writes:

>THERE IS NO SUCH THING AS "THE MIME FORMAT."
>
>The basic unit of information in the MIME architecture is the _entity_ --
>an arbitrary stream of bytes. There is, of course, the ubiquitous
>message/rfc822 format, which, through MIME techniques, can _contain_
>any type of entity.

(He's been ranting on about this in other fora as well.)

I personally think that Dan, in a severe attack of "Hupty-Dumptyism",
is trying to make the word mean what he wants to read into it rather
than use it in the way that most people will understand it.  After
all, the MIME standard clearly defines a single, all-encompassing
message format.  Please don't do this to us, Dan!

However, Dan does have a point.  A (tiny) part of the MIME standard is
concerned with defining standard names for many existing (and some
newly invented) data formats.  MIME also provides a scheme into which
such standard names must fit (the type/subtype scheme), a syntax to
specify parameters for types, a way to get new names standardized
(the IANA registry), and a way to make local extensions to the scheme
(the x-* convention for types and subtypes).

Use of the standard names, in particular, makes it possible for users
to have their personalized mapping from types/subtypes to viewers.
Nathaniel Borenstein's "metamail" tool is an example of a program that
supports such a mapping (its "mailcap" file).

So, I second Dan's motion to use MIME's naming scheme for data types,
even if MIME's content-transfer-encoding and use of headers are not of
interest.

--Guido van Rossum, CWI, Amsterdam <guido@cwi.nl>
"He used SARCASM.  He was VICIOUS"
Newsgroups: comp.infosystems.gopher,comp.infosystems.wais
From: MAHE@YaleVM.YCC.Yale.Edu
Subject: Re: mailing info to gopher/wais servers - how ??
Organization: Yale University
Date: Wed, 16 Dec 92 14:39:48 EST

I'd like to second Mr Serials's recommendation about the procmail
Unix utility.  I've been using for several months now to process
incoming mail, and it's been absolutely foolproof and trouble free.
 
I'm subscribed to one list that sends regular bulletins and occasional
extra announcements.  The bulletins get filed without needing any
attention from me, and I get the extra annoucements in my regular
mail, where I can decide to plop them down in the same directory
or toss them out.  Several other lists get their output filed
completely transparently.  This allows me to use a single alias
for problem reports and submissions, since the submissions don't
usually require any human attention.
 
Procmail is free, and was very easy to setup.  In a couple hours
it was all ready, basically you only need to make a .procmailrc
file in your home dir and tell it what to do with mail from specific
sources.  For once the documentation is adequate, and comes with a useful
set of examples.  Procmail can use any number of criterion, each modeled
on grep, to select mail, for instance you can specify the sender and
the subject, and the many varieties of 'To:'.  It can forward mail,
and/or write the body and/or the header of the message in one
or more places.
 
Granted, it's not ideal in that there's no artificial intelligence to
tell it where a new message can be best placed :-), directories and .cap
files have to be ready and waiting, etc...  But I recommend it as
a painless and reliable way to cope with regular submissions.
 
Marie-Christine
mahe-marie-christine@yale.edu
From: fogel@jester.usask.ca (Earl Fogel)
Newsgroups: comp.infosystems.gopher
Subject: Re: .links files
Date: 14 Dec 1992 20:09:32 GMT
Organization: University of Saskatchewan
NNTP-Posting-Host: jester.usask.ca

In article <1992Dec8.210129.3080@gumby.cc.wmich.edu> scott@mickey.acs.wmich.edu (Julie Scott) writes:
>Perhaps this is an obvious thing, but I have been unable to figure it out  
>from the documentation I have (man pages).  I have a .links file in my  
>main gopher data directory.  My eight entries (one for each subdirectory)  
>are of the form
>
>	Name=About Gopher
>	Numb=1
>
> ...

The short answer is:  use .links files to add new entries to gopher menus,
		      use .cap directories to modify existing entries.

So, get rid of your .links file, and create  a .cap directory.  Then,
for each file you want to renumber, create a one-line file in the .cap
directory, with the same name as the original file, containing, e.g:

	Numb=1


Earl Fogel
-------------------------------------------------------------------
fogel@jester.usask.ca		Computing Services, Room 56 Physics
Phone: (306) 966-4861		University of Saskatchewan
Fax:   (306) 966-4938		Saskatoon, Sask. CANADA, S7N 0W0
From: kann@picasso.cc.rochester.edu (Kirk Anne)
Newsgroups: comp.infosystems.gopher
Subject: Re: Disclaimer page on client startup...
Date: 14 Dec 92 22:43:53 GMT
Organization: University of Rochester - Rochester, New York

In <1992Dec14.174253.12981@news.acns.nwu.edu> Albert-Lunde@nwu.edu (Albert Lunde) writes:

>In article <1gck66INNk3q@phantom.gatech.edu> ccoprmm@phantom.gatech.edu (Michael Mealing) writes:
>>  With the pervasivness of lawsuits it has been recommended that if
>>we setup a CWIS with gopher that ALL clients have a disclaimer page
>>appear before any connection to the system. I know this can be done
>>easily with shell scripts and other such stuff but how hard would
>>it be for all client programmers to add a disclaimer page to the
>>command line? Something like:
>>gopher -disc /usr/local/etc/disclaimer.txt gopher.gatech.edu 70
>>
>>  I can do this in about 5 minutes on the UNIX implementation but I 
>>was wondering if I could talk the other implementors into doing it?

>I think you are asking for something the protocol does not support.

What if there was a standard file that existed in the root directory similar
to the message that is displayed on some of the 'ftp' sites?

>Since there is no connection between client and server between
>transactions it is pretty hard for the server to tell what the
>start-up is.

On receiving the directory listing, if a particular file name appears,
display it in a dialog box or on the screen first before displaying the
file list (minus the particular file).

Just my two cents...

Kirk Anne				kann@gopher.cc.rochester.edu
Gopher Prophet/UNIX Consultant 		Phone: (716) 275-2811
University of Rochester			Fax:   (716) 273-1023
Rochester, NY 14627
From: emv@msen.com (Edward Vielmetti)
Newsgroups: comp.infosystems.gopher
Subject: Re: replicating popular resources
Date: 15 Dec 1992 21:05:06 GMT
Organization: Msen, Inc. -- Ann Arbor, Michigan
Distribution: world
NNTP-Posting-Host: garnet.msen.com
X-Newsreader: TIN [version 1.1 PL8]

JQ Johnson (jqj@duff.uoregon.edu) wrote:
: One of my users complained just now that she couldn't access the Weather
: in our gopher server.  We implement it as a link to ashpool.micro.umn.edu,
: which is (not unreasonably; it's only a computer) down at the moment.

I've re-pointed my weather services to 
	wx.atmos.uiuc.edu
the U of Illinois "Weather Machine".  Aside from being at least as
up to date as the U Minnesota data, it's got color weather maps in it.

My understanding of the ashpool setup is that it's one step removed
from the "real" data which comes from U of Michigan's "weather underground"
via some hairy scripts; the UIUC setup appears to be designed to be
used as a gopher system rather than having it built on top of terminal-based
services.

  Edward Vielmetti, vice president for research, Msen Inc. emv@Msen.com
        Msen Inc., 628 Brooks, Ann Arbor MI  48103 +1 313 998 GLOB

Newsgroups: comp.infosystems.gopher
From: kemp@uiatma.atmos.uiuc.edu (John Kemp)
Subject: HPUX GOPHER1.1 INSTALL TRICKS
Organization: University of Illinois, Urbana-Champaign
Date: Tue, 15 Dec 1992 08:32:32 GMT


Here's three hints for getting gopher1.1 going
on an HP720 running HPUX8.07.  I used the following
option flags, but these can definitely trip you up,
so you might want to try something different:

-g -Aa -D_HPUX_SOURCE -Wl,-a,archive -Dhpux -Dunix -DSYSV -DUSG

HINT #1: the above "-Dhpux -DUSG" breaks the define 
logic in daemon.c in the gopherd source code.  You end up with
the call "setpgrp()" when what you really want is "setsid()".
You can either just hardcode in the change, or figure out a 
way to compile without "-DUSG".  

HINT #2: that darn socket bound to port 70 just doesn't seem
to free up in any predictable way.  Try starting in debug mode
"gopherd -D" until you can see that the bind is working.  Then
you can CTRL-C and start up the server normally.  I know it's a
pain, but I don't know how you are going to handle this in the 
code.

Paul Gibbs also helped me in this area with the following 
advice.  In short he says to bind with resuseaddr set to 0,
and to kill *WITHOUT* -9 when you are working on the server.

>>>After the socket is created and before it is bound, add:
>>>     if (setsockopt (sockfd, SOL_SOCKET, SO_REUSEADDR, &o, sizeof o) < 0)
>>>        err_dump("Setsockopt to REUSSADDR failed");
>>>With "int i=o;" as the declaration for o.
>>>...
>>>By the way, I found that if I kill the server without the "-9", I don't get
>>>this problem.  If I "kill -9", I have to put in the above hack to get it to
>>>work.  

HINT #3: make sure you define the access in the gopherd.conf
file.  I could have sworn that it said in the docs that the access
defaults to an open mode.  It doesn't.  The default is no access
by anybody, including you while you are debugging.  ;-)

Got it?  Gee, it's only 2:30 AM.  What do I do now?  Oh, I remember.
Time to add more entries to the gopher server!  ;-)

TTFN,
--------  john kemp            (  (  )_  internet - johnkemp@uiuc.edu
  -----                       (  (   __)   
   ---    univ of illinois   (_ (   __)    bitnet - {uunet,convex}
   --     dept of atmos sci  .(____).               !uiucuxc!uiatma!kemp
   -      105 s gregory ave    ...          phone - (217) 333-6881
    -     urbana, il 61801    ...             fax - (217) 244-4393
From: cshotton@oac.hsc.uth.tmc.edu (Chuck Shotton)
Newsgroups: comp.infosystems.gopher
Subject: Re: mailing info to gopher/wais servers - how ??
Date: 16 Dec 1992 20:05:00 GMT
Followup-To: comp.infosystems.gopher,comp.infosystems.wais
Organization: Academic Computing

In article <1992Dec15.223305.21532@cc.uow.edu.au>, kirk@cc.uow.edu.au
(Kirk) wrote:
> 
> 
> G'Day,
> 	I am interested to find out if anyone has setup programs or 
> procedures that enable them to email files to gopher or wais servers and have 
> the information automatically placed into the relevant area/index. A while 
> back someone posted an article about how to do something like this which I 
> think also included converting Microsoft Word documents to plain text.
> 

We have a relatively simple program that uses deliver to allow mail
messages sent to a specific account, with a specific subject, by a specific
user to be posted to a specific gopher subject. The code can be found on:
oac.hsc.uth.tmc.edu, in the directory /public/unix/gopher. You'll need to
get the files mailman.c and deliver.tar.Z (if you don't already have
deliver.)

This program allows you to build a table of subjects, authorized "posters",
and gopher destinations, parses incoming mail messages and the sends the
contents to the gopher destination. Hope it helps.

--_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-
Chuck Shotton                      |    
Ass't Director, Academic Computing |       "This space for rent."
UT Health Science Center Houston   |  
cshotton@oac.hsc.uth.tmc.edu       |         
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-
Newsgroups: comp.infosystems.gopher,comp.infosystems.wais
From: JONESD@kcgl1.eng.ohio-state.edu (David Jones)
Subject: VMS gopher client update (revision d)
Organization: The Ohio State University
Date: Wed, 16 Dec 1992 19:55:45 GMT

I've added directory caching, a much requested feature, to the gopher client
I distribute through anonymous FTP on job.acs.ohio-state.edu.  With directory
caching, backtracking up the menu heirarchy is much snappier.

The distribution is a VMSHARE file, which when invoked as a command procedure
upacks itself into source files.

In case you haven't been following the changes that I've been making to
the boombox 0.6 version, here is an extract from the AAAREADME.TXT

----------------------------------------------------------------------------
Items changed (13-SEP-1992):

    Telnet command changed to UCX format (i.e. "telnet host port" instead of
     "TELNET/PORT=port host").

    Fixed setsockopt() calls in gopher.c to work around bug in UCX 2.0.
    Conditionally compile setscokopt() calls that Wollongong doesn't
    support.

    Created wollongong.opt options file.

    Modified screen management to set scroll region based on size of
    screen (supports 48-line DECterms now).

    Perform cannonical interpretation of control-Z (e.g. exit program).

    Fixed showfile()'s failure to close the connection.

    Optimize reads done by readline() and readfield().  Character-at-a-time
    I/O is horribly inefficient with UCX (2K QIOs/sec when receiving text).

    Fixed bug in feed_a_gopher/feed_gophers that was causing infinite
    loops.

    Fixed bug in querying index servers (wasn't sending search string).

Items changed to 'c' release (OCT-1992).

    Increased storage for selector string.  The newer gopher servers do
    not follow the convention of keeping selector strings less than 255
    characters and this was causing the client to crash.

    Cache address translations to speed up connect times.

    Minor optimization in MANAGER.C to make few SMG$PUT_CHARS calls.

    Make connect fails not abort the program.

    Added support for special 'background' operations, whereby gopher is
    run as a sub-process which executes pageer and telnet commands by
    attaching back to the parent rather than spawning a new process each
    time.  The new file GOPHER_BG.COM is used to run gopher in background
    mode.  If you run the gopher image as a normal foreign command,
    it reverts to it's previous method (spawning).

Items changed to 'd' release (DEC-1992).

   Cache directory listings.  Save up to the last 20 directories retrieved
   and uses the cached entry when you go back to a directory instead of
   re-retrieving it.

   Hopefully improved multinet support.
----------------------------------------------------------------------------

David L. Jones               |      Phone:    (614) 292-6929
Ohio State Unviversity       |      Internet:
1971 Neil Ave. Rm. 406       |               jonesd@kcgl1.eng.ohio-state.edu
Columbus, OH 43210           |               jones-d@eng.ohio-state.edu

Disclaimer: A repudiation of a claim.
From: lindner@mudhoney.micro.umn.edu (Paul Lindner)
Newsgroups: comp.infosystems.gopher
Subject: Re: replicating popular resources
Date: 16 Dec 92 16:40:24 GMT
Organization: University of Minnesota, Minneapolis

In <1glc5eINNpc3@pith.uoregon.edu> jqj@duff.uoregon.edu (JQ Johnson) writes:

>One of my users complained just now that she couldn't access the Weather
>in our gopher server.  We implement it as a link to ashpool.micro.umn.edu,
>which is (not unreasonably; it's only a computer) down at the moment.

>It seems to me that there are a number of high-visibility gopher resources
>that would do well to be invisibly replicated for greater availability
>(and perhaps for load sharing).  There are at least two problems, though:
>(1) the lack of a protocol to allow clients to transparently locate
>replicas of a gopher link, and (2) the lack of protocols and methodologies
>for maintaining replicated gopher databases.

With impending gopher+ (taking a break to read news :-) we will have a
framework to at least somehow specify replicated servers.  I've had
some ideas about this, consider the following scheme:

Here's how I envision it.  A server can link to another server,
however the link points to the local server.  The server can then
fetch the item and store it locally if the usage is high enough (this
is an example of a replication heuristic)

The subsidiary servers would request the master to send them updates
as they come in.  Pros: the master server knows who's linking to it,
plus we eliminate the polling that gopherclone, etal do.  This is an
example of a callback scheme.

There was a paper published a while back that had information about
replication heuristics using ftp, it was pretty cool, I'll have to dig
up the reference to it..
--
 | Paul Lindner | lindner@boombox.micro.umn.edu   | Slipping into madness
 |              | Computer & Information Services | is good for the sake
 | Gophermaster | University of Minnesota         | of comparision.
///// / / /    /////// / / / /  /  /  /   /      //// / / / /  /  /  /   /
Organization: Statistics, Carnegie Mellon, Pittsburgh, PA
Newsgroups: comp.infosystems.gopher
Date: Tue, 15 Dec 1992 08:21:23 -0500 
From: Michael Meyer <mikem+@andrew.cmu.edu>
Subject: suggested modification to gopherd

It would be very useful if one could include a login-name other than
anonymous in the links to FTP services.  For example, the netlib service
allows unauthenticated logins via user "netlib".  I'd like to build a
gopher link to that that service, but can't --- unless I hack it into
the source code.
--Mike
Mike Meyer, Computing Services and Department of Statistics, 
	    Carnegie Mellon University
Date: Tue, 15 Dec 1992 08:42:16 +1000
Original-To: gopher-news@boombox.micro.umn.edu
From: tony@info.anu.edu.au
Subject: Australian mailing list
Newsgroups: comp.infosystems.gopher
Distribution: comp

Hi

There is an Australian mailing list for gopher, wais and other NIR tools
set up called wombat@aarnet.edu.au.

A wombat is a large burrowing marsupial (about 40kg)....
Wombats have a reputation for singleness of purpose and can be a bit silly.

Regards from down under.

Tony
______________________________________________________________________
Tony Barry. Head, Centre for Networked Access to Scholarly Information

    Australian National University Library     | fone   +61 6 249 4632
GPO Box 4 Canberra City A.C.T. 2601, AUSTRALIA | phax   +61 6 249 4063
  tony@info.anu.edu.au, Tony.Barry@anu.edu.au  | telex  10717252     
 

Newsgroups: comp.infosystems.gopher
From: gilbertd@sunflower.bio.indiana.edu (Don Gilbert)
Subject: Re: Allowing clients to hop into the middle of a Gopher tree
Keywords: client hierarchy microlabs
Organization: Biology, Indiana University - Bloomington
Date: Thu, 17 Dec 1992 01:51:22 GMT

In article <1992Dec16.214459.25297@msuinfo.cl.msu.edu> rww@mugwump.cl.msu.edu (Richard W. Wiggins) writes:
>Has anyone modified a client to allow it to fire up a 
>Gopher session jumping into the middle of a tree?  Ie, rather
>than starting up with the null selector string to get
>the root menu, the client knows the string for a particular
>item, and it fires up and sends that string to begin with?

This is the way GopherApp on the Mac works, essentially. Any window
of gopher items you see can be saved to disk as a folder of gopher items.  
Single or multiple items can be copied and pasted into a gopher folder 
that you may save to disk.  I regularly keep a "Biology" and a 
"Phone Books" and a "Library Catalogs" and similar such GopherApp documents 
for the people using our department file server, to bypass some 
of the maze of finding things in gopherspace.  

These gopher folders are just the equivalent of the ".link" files found on
gopher servers, but your average Mac user can make one with no
training by pointing and clicking.

GopherApp doesn't "send that string to begin with", but displays all 
items from any gopher folder that you open, then it waits for you to click 
on one before it reaches out into gopherspace.  Sure, I have to refresh
these documents from time to time.  But it isn't much effort.

-- 
Don Gilbert                                     gilbert@bio.indiana.edu
biocomputing office, biology dept., indiana univ., bloomington, in 47405
Newsgroups: comp.infosystems.gopher
From: ellis@nova.gmi.edu (Stew Ellis)
Subject: .cap files for subdirs
Organization: GMI Engineering&Management Institute, Flint, MI
Date: Sun, 13 Dec 1992 22:24:51 GMT

I have a subdirectory in my gopher that consists of of unfriendly file
names.  This is a subdir of a directory that is symbolically linked.  I know
I read somewhere how to maintain separate trees for the resource files and
the .cap files, but I cannot find the reference.  Several attempts at
reinventing it have been unsuccessful.  A complete pointer to TFM to R would
be appreciated.


--
--                                                        ___________________
  R.Stewart(Stew) Ellis, Assoc.Prof., (Off)313-762-9765  /   _____  ______ 
  Humanities & Social Science,  GMI Eng.& Mgmt. Inst.   /        / /  /  / /
  Flint, MI 48504      ellis@nova.gmi.edu              /________/ /  /  / /
Newsgroups: comp.infosystems.gopher
From: mitra@pandora.sf.ca.us (Mitra)
Subject: Re: MIME in Gopher (was Re: Gopher+ Considered Harmful)
Organization: Pandora Systems
Date: Tue, 15 Dec 1992 17:57:41 GMT
X-Newsreader: TIN [version 1.1 PL6]

Is there a collection of mime documents available via Gopher, I'd like
to test our client against them.

- Mitra

Newsgroups: comp.infosystems.gopher
From: werner@physics.uq.oz.au (Michael Werner)
Subject: gopher1.1
Reply-To: werner@dirac.physics.uq.oz.au
Organization: Department of Physics, University of Queensland
Date: Wed, 16 Dec 1992 23:45:11 GMT

I have set up a gopher1.1 server and things appear to work fine 
except for one thing. Each new operation (i.e look at a directory)
by the client (i.e. xgopher1.2) results in a new gopherd process.
Is that the way it is suppose to work ? I am running it under inetd
so I thought for every new connection inetd would create a new gopherd
process but each gopherd process would know which client it was talking to.
This doesn't appear to be the case. So how come it has been written this way?
-- 
Yours,

Mike

----------------------------------------------------------------------------
+                                                                          +
+    *		  *			Michael Werner		           +
+     *		 *	    		werner@dirac.physics.uq.oz.au      +
+      * 	*			Theoretical Quantum Optics,        + 
+       -------		                Department of Physics,             +
+      *       *                        University of Queensland.          +
+     *		*			St. Lucia. 4072. Australia         +
+    *           *                                                         +
+                                                                          +   
----------------------------------------------------------------------------