HDTenEightyP/NetNews huggingface dataset:
From: SEB1525@MVS.draper.com (Steve Bacher)
Subject: Re: Personalizing gopherspace
Organization: Draper Laboratory
Date: Sat, 15 Aug 1992 21:34:00 GMT

In article <1992Aug14.181144.16439@midway.uchicago.edu>,
davet@granta.uchicago.edu (David Thomas) writes:

>Has anybody thought about changing the gopher clients (I'm thinking
>particularly about the curses and X clients, but it should presumably
>apply to the others) to do the following: Arrange that when the client
>starts, instead of contacting a server, it looks in say $HOME/gopher,
>and if it finds it, presents the data in the usual way.  (If there's
>no such directory then it goes on to look for a (default) server.)  A
>user could still make contact with the rest of gopherspace by
>including link files in ~/gopher, but would also have access to
>whatever data he or she keeps locally.
>
>There are two main advantages that I see to this scheme.  First, a
>user can use the same tool (gopher) for browsing their own information
>as for searching through the internet, without having to run a server
>and make (possibly sensitive) personal data at least partially public.
>Secondly, by populating your own gopher directory with links you can
>both access services that may not appear elsewhere in gopherspace
>(like telnet'able information services) and provide quick access to
>your own favorite gopher holes -- when I come across a useful
>resource, instead of trying to make a mental note of where it is, how
>I accessed it (gopher, WAIS, ftp) and what path to take to get there,
>I just put a link into my own private map of gopherspace.

I've built exactly that sort of support into the MVS/TSO gopher client
that I'm developing.  Of course, this isn't Unix, but the same basic
principles apply, and I'm hoping that this can be done easily
for the other clients.

It works like this:  If a link (could be your top-level menu or initial
path spec) has a host name of "-", then the access is assumed to be
local (i.e. no server is involved).  The bulk of the Gopher MVS server
code has been isolated and linked in with the client code, and so you
get exactly the capability you describe.  The authorization checks done
by the MVS server (which I also added) are bypassed in this mode, since
you presumably should be able to access your own private data, and your
favorite installation security system (e.g. RACF or ACF2) ought to take
care of the rest.

Menu items with a host name of "+", meaning "same host as me", are
treated correctly in this mode as well:  if the access is local
(serverless), the + is replaced internally with "-" and the same
kind of access is assumed.  And, as you stipulate, your local data
can still have links to actual Gopher servers, which work as usual.

--
Steve Bacher (Batchman)                 Draper Laboratory
Internet: seb@draper.com                Cambridge, MA, USA
Newsgroups: comp.infosystems.gopher
From: namra@magnus.acs.ohio-state.edu (Nasir K Amra)
Subject: Instructions on how to access WAIS servers via Gopher
Organization: The Ohio State University
Date: Wed, 19 Aug 1992 14:39:53 GMT


	I've installed MacGopher on my Macinstosh and really like it a
lot. However, I'd like to access WAIS servers via MacGopher. Is this
possible and if so how is this done? ( I am a relative novice to both
the Gopher and WAIS worlds so I would appreciate detailed instructions
or pointers to help documents).
-- 
---------------------------------------------------------------------
Nasir K. Amra				     amra@med.ohio-state.edu
Laboratory for Knowledge Based Medical Systems
571 Health Science Library,376 W. 10th , Columbus, Ohio, 43210
Newsgroups: comp.infosystems.gopher
From: davet@granta.uchicago.edu (David Thomas)
Subject: Personalizing gopherspace
Organization: University of Chicago, Astronomy and Astrophysics
Date: Fri, 14 Aug 1992 18:11:44 GMT


Has anybody thought about changing the gopher clients (I'm thinking
particularly about the curses and X clients, but it should presumably
apply to the others) to do the following: Arrange that when the client
starts, instead of contacting a server, it looks in say $HOME/gopher,
and if it finds it, presents the data in the usual way.  (If there's
no such directory then it goes on to look for a (default) server.)  A
user could still make contact with the rest of gopherspace by
including link files in ~/gopher, but would also have access to
whatever data he or she keeps locally.

There are two main advantages that I see to this scheme.  First, a
user can use the same tool (gopher) for browsing their own information
as for searching through the internet, without having to run a server
and make (possibly sensitive) personal data at least partially public.
Secondly, by populating your own gopher directory with links you can
both access services that may not appear elsewhere in gopherspace
(like telnet'able information services) and provide quick access to
your own favorite gopher holes -- when I come across a useful
resource, instead of trying to make a mental note of where it is, how
I accessed it (gopher, WAIS, ftp) and what path to take to get there,
I just put a link into my own private map of gopherspace.

It seems like this shouldn't be a difficult problem, although it would
mean copying some of the server code into the clients.  Is anybody
else out there thinking along these lines?
-- 
David Thomas                        University of Chicago
davet@oddjob.uchicago.edu           Astronomy and Astrophysics
Newsgroups: comp.infosystems.gopher
From: datta@cs.uwp.edu (David Datta)
Subject: Re: cookbook for secure gopher wanted
Organization: University of Wisconsin - Parkside
X-Newsreader: Tin 1.1 PL4
Date: Fri, 14 Aug 1992 01:30:32 GMT

jqj@duff.uoregon.edu (JQ Johnson) writes:
: My concerns:
:    - "builtin" internal pager doesn't seem to work in gopher 1.02, and
:      PAGER=more allows escaping to vi and thence to arbitrary commands

To counter the "escape to vi" or other escapes, I added a new option to
the verion of more on our machine, a simple "-S" option that stops any
exec lines in more. Then I changed the PAGER definition in gopher to
use -d -S. The login gopher runs a shell of /usr/local/bin/gophers
which is a script that sets up env things.

:    - by default, "gopher -s" allows mailing of downloaded files

Actually, if I remember correctly, 1.01 did not allow mail. I actually
prefer to allow mail so the "anonymous" user has a way to get files
back to their machine.

:    - we believe that good Internet citizenship requires that we not
:      offer unauthenticated telnet to off-campus locations.  However, we
:      do allow unauthenticated telnet to oncampus locations, e.g. the
:      gateway machine

If this is the case, then you will have to disable the telnet option of
the gopher client that you use for anonymous access.

-- 
-Dave datta@cs.uwp.edu: Man made machines make music for the man.  Now
machines make music while the man makes plans. A second generation, a
generation lost. While the man prepares for the holocaust.- A Flock of Seagulls
From: dgaraffa@bigmac.mskcc.org ("Dave Garaffa" )
Newsgroups: comp.infosystems.gopher
Subject: Unix client to auto-load after login: gopher (how?)
Date: 21 Aug 92 17:16:52 GMT
Reply-To: "Dave Garaffa"  <dgaraffa@bigmac.mskcc.org>
Distribution: comp
Original-To: gopher-news@boombox.micro.umn.edu

Paul Lindner & The Gopher News Group,
 
Sorry if this is a dumb question (I am still very new to unix)... anyway I would
like to setup the unix gopher client in a similar fashion to the client you have
setup @ umn (ie: login: gopher   will bring you directly into the client)  I 
know all unix's are *NOT* the same (I am running A/UX) but could you point me in
the right/general direction as to how to get my system setup the same way?

Thanks for your time!

Dave,
Macintosh Support Manager
Memorial Sloan Kettering Cancer Center
1-212-639-3738
From: thacker@cc1.unt.edu (Mark D. Thacker x2568)
Newsgroups: comp.infosystems.gopher
Subject: Re: Problem searching with PC Gopher
Date: 19 Aug 92 18:59:59 GMT
Article-I.D.: cc1.thacker.56.714250799
Organization: Computing Center, UNT

In article <1992Aug19.000004.9502@talon.ucs.orst.edu> hanusj@bionette.cgrb.orst.edu (Joe Hanus) writes:
>From: hanusj@bionette.cgrb.orst.edu (Joe Hanus)
>Subject: Problem searching with PC Gopher
>Date: Wed, 19 Aug 1992 00:00:04 GMT
>We're putting together an experimental gopher to locate data on
>microbial cultures.  Gopher browses through the directory tree 
>fine. The searching facility works from Mac
>Internet Gopher, MacGopher,  Unix Gopher clients.  However my PC gopherII
>1.04 fails to return any successful searches.  I get the "When I
>looked, I didn't find anything" message.  The searching and
>indexing appear to be working because when you browse down
>through the directories, the files that contained the search
>strings show the appropriate text highlighted.  If you search for
>text that is not in any of the files, the "search not successful,
>here is the whole catalog" message appears.   My PC gopher client
>is able to perform searches on other servers however.  IUB genetics
>and Molecular biology servers, various campus newspapers can 
>searched with no problem.
>
>Any ideas for what is wrong?
>
>------------------------------------------------------------------------------
>Joe Hanus                            | E-MAIL hanusj@cgrb.orst.edu
>Microbial Germplasm Database         |
>Dept. of Botany and Plant Pathology  | Phone  (503)-737-5300
>Oregon State University              | FAX    (503)-737-3573
>Corvallis, OR 97331-2902             |
>______________________________________________________________________________

Well, the problem is (and the author knows this), PC Gopher II is written in 
Pascal, which has a limit of 255 chars per STRING type.  Unfortunetly, 
searches can result in longer than 255 chars returned.  This means the PC 
Gopher client doesn't work correctly.  Note that the author is well aware of 
the limitation and is planning on (correct me if I am wrong) re-writting the 
client in C/C++.

Mark
===============================================================================
Mark Thacker                Bitnet : MARK@UNTVAX
CC1 Novell LAN Manager      THENET : NTVAXA::MARK
Computing Center            Internet : MARK@VAXB.ACS.UNT.EDU
University of North Texas         or : THACKER@CC1.ACS.UNT.EDU
===============================================================================
From: zlsiimw@mcchpc.mcc.ac.uk (Mark Whidby)
Newsgroups: comp.infosystems.gopher
Subject: Re: Viewing files returned by gopher searches
Keywords: Highlighting getting rid of escape sequences
Date: 17 Aug 92 08:22:21 GMT
Reply-To: M.Whidby@mcc.ac.uk
Organization: Manchester Computing Centre

In article <1992Aug15.200204.3594@cs.cornell.edu>, raman@cs.cornell.edu (T. V.
Raman) writes:
|> 
|> Hi!
|> 
|> I am using a vt100 terminal with pager set to less.
|> 
|> When I perform searches using gopher, the returned files have the hit
|> words sorrounded by highlighting characters which are being literally
|> displayed by my terminal.  Is there some way of getting rid of these
|> control sequences?

You should be using the -r and -f options to less; this will result in
the highlighted text being displayed properly. I also use -i to make
searches case insensitive and -w to make lines past the end of file
appear as blank lines (rather than being represented by tilde ~).
-- 
_____________________________________________________________
Mark Whidby, Distributed Systems, Manchester Computing Centre
From: zlsiimw@mcchpc.mcc.ac.uk (Mark Whidby)
Newsgroups: comp.infosystems.gopher
Subject: Bug in gopherd 1.02 waisindexquery
Date: 22 Aug 92 10:15:27 GMT
Reply-To: M.Whidby@mcc.ac.uk
Organization: Manchester Computing Centre

In Waisindex.c there's the following:

 sprintf(score,"%3d ",best_hit.weight);

 waislog(0,99,"%s: Score %3d:%s",SearchWords,best_hit.weight,cp);

which is wrong and was causing core dumps in my waisindex directories
(67Mb in one instance!). I'm not sure what 'cp' is supposed to be at this
point so I just changed this to:

 sprintf(score,"%3d ",best_hit.weight);

 waislog(0,99,"%s: Score %s",SearchWords,score);

-- 
_____________________________________________________________
Mark Whidby, Distributed Systems, Manchester Computing Centre
Date: Mon, 17 Aug 92 10:50:43 CDT
From: fxa@boombox.micro.umn.edu ("Farhad Anklesaria" )
Original-To: gopher-news@boombox.micro.umn.edu
Subject: Gopher+ reference server available for client tests.
Newsgroups: comp.infosystems.gopher
Distribution: comp

A reference Gopher+ server is up on yoyo.micro.umn.edu; port 2000.
This server is basically for client writers to test their clients.
Note that this is not a "real" server: it's a temporary two-page hack
test-bed for clients while we put real servers together.  We hope gopherspace
will have Gopher+ aware and savvy clients available when the first real
Gopher+ servers emerge.

The reference server still needs a few last tweaks.... and its contents
may change a bit as client test needs and bugs dictate.

Here is the +ABSTRACT block for the server's root directory:
-------
+ABSTRACT:
 This is a reference (test) Gopher+ server for client writers to
 use in checking their clients.  It does little except
 1. use all three forms of data transfer
 2. allows use of the ! command for getting attribute information
 3. allows use of the $ command for getting full directory attrib listing.

 Note: Everything points back to itself! So don't get confused 'eh?
 This is a hack server, just intended for client tests.
 If you aim old clients at it, you will just get back everything in
 the old gopher way (with trailing plus chars though).
 Have fun.  Bugs to gopher@boombox.micro.umn.edu.

 The server is an ugly hack.  Don't ask...
---------------


F.
--
Farhad Xerxes Anklesaria
Skanky Gopher Hairballs Inc.                    "If it wasn't really skanky,
University of Minnesota                          it wasn't done here."
fxa@boombox.micro.umn.edu
From: daniel@bauhaus (Daniel Torrey)
Newsgroups: comp.infosystems.gopher
Subject: Re: Comments about Gopher+
Date: 17 Aug 92 18:28:16 GMT
Distribution: comp
Original-To: bkc@omnigate.clarkson.edu (Brad Clements)
Original-Cc: gopher-news@boombox.micro.umn.edu, gopher@boombox.micro.umn.edu
X-Mailer: ELM [version 2.3 PL11]

Brad Clements :
. 
. I have a few suggestions for the Gopher+ docs and concept. Hopefully not
. too late.
. 
. 1. The document should specify a maximum selector string length. All the docs
.    say is that it could be more than 256 chars, but no maximum is given. This
.    should be stated explicitely.

Why?  Unless you're writing in Pascal, this isn't really an issue, and if you
are writing in Pascal, you'll need to fake a c-string type anyway...

. 2. The VIEWS return value seems complicated. I don't think its necessary
.    to have the < > around the value. It requires extra parsing to get out of

The <> make it easier to parse, I think.  Read until the <, everything up to
the > is important, toss the rest.

.    the way. Also, I think the returned value should be in decimal octects,
.    not K.

Users think in K.  For that matter, so do I.

.    Does this imply that the Gopher+ protocol will allow the TCP connection
.    to stay open after the data is returned? If not, then there isn't any
.    point in offering the DATA <CR>.<CR> return mode.

Older clients need the <CRLF>.<CRLF>.

. 
.    A month ago I suggested that you allow the server to keep the connection
.    open if it so desires. I received no reply from that suggestion, not even
.    a reason as to why it wasn't acceptable.

Since users spend 80% of their time reading lists of files, or the files
themselves, it's a waste of process table space to hold the connection open
for any longer than it takes to ship the data.  Why clog up the server?
. 
.    This is expensive in terms of system overhead. If a server were allowed
.    to keep a connection open after returning the data, then the next
.    request from the same connection could be answered immediately without
.    the overhead of a fork.

The next request for data may be five minutes later.  Seems like a lot more
overhead that way to me.

. I'd appreciate hearing at least an acknowledgement of receipt this time..

Reading you loud and clear...


-- 

Daniel A. Torrey                           daniel@bauhaus.micro.umn.edu
University of Minnesota                                  (612) 626-8663
CIS/UAP/ETC               In gopherspace, no one can hear you scream...
From: jqj@duff.uoregon.edu (JQ Johnson)
Newsgroups: comp.infosystems.gopher
Subject: Re: Comments about Gopher+
Date: 18 Aug 92 18:35:58 GMT
Article-I.D.: nntp.1992Aug18.183558.14109
Distribution: comp
Organization: University of Oregon Network Services

Daniel Torrey (and others), responding to Brad Clements, say:
>. the way. Also, I think the returned value should be in decimal octects,
>. not K.
>Users think in K.  For that matter, so do I.

Is there any direct evidence that "users think in K"?  I believe that the
human factors literature and anecdotal evidence support the opposite
conclusion, that apart from us nerds nobody thinks in "K" for amounts of
text.  For that matter, "K" is ambiguous:  some people (scientists and
communications engineers, for example) think it means "kilo" as in metric
system, and so interpret 19.2K to mean 19200.  Others (RAM manufacturers,
for example) think in binary, and interpret 19.2K to mean 19589.

Units for file sizes are particularly confusing, since many Unix systems
report file sizes in "blocks" which might be 512 octets, 1024 octets,
4096 octets, or something else depending on the context.  Let's not
exacerbate the problem!

In addition to being less confusing to normal users, having data returned
in decimal octets would allow finer granularity for small values.  It
seems likely to me that people will much prefer to know that the value is
500 characters rather than 0K.

-- 
JQ Johnson
Director of Network Services		Office: 250E Computing Center
Computing Center			Internet: jqj@ns.uoregon.edu
University of Oregon			voice:	(503) 346-1746
Eugene, OR  97403-1212			fax: (503) 346-4397
From: lindner@mudhoney (Paul Lindner)
Newsgroups: comp.infosystems.gopher
Subject: Re: Resource Discovery Service for gopher
Date: 12 Aug 92 17:59:28 GMT
Reply-To: lindner@boombox.micro.umn.edu.
Distribution: comp
Original-To: Peter.Hausken@usit.uio.no
Original-Cc: mtm@SUMEX-AIM.Stanford.EDU, gopher-news@boombox.micro.umn.edu
X-Mailer: ELM [version 2.3 PL11]

Peter.Hausken@USIT.UiO.NO sez:
. 
. John M. Sellens writes:
. >
. >	We have seen a variety of reasons to "hide" something from Gopher. We 
. >have a variety of information tools which work in pretty much the same data 
. >directories. Different tools have different requirements, and sometimes require 
. >their own files within this tree. Having this administrative junk appear in 
. >Gopher is senseless and confusing. Our FTP server contains server status files 
. >which are absolutely off limits to Gopher. Digital Librarian on the NeXT 
. >requires a self-referencing symlink so it can co-exist with the index files we 
. >have built. Gopher does not need to see this, and is terribly confusing to 
. >novices. 
. 
. I ve experienced a problem with this strategy when using waisindex to index
. all files in such directories. The files are hidden to Gopher, but wais
. picks them up and indexes them and they can be retrieved that way. Just
. try to search for Type= and you ll have all the .link files. 
. 
. Does someone have a good solution to hide unwanted info from waisindex?
. 

In 1.01 I altered the searcher so that it wouldn't return .cache
files.  This can be modified to not return other stuff as well.

It might be possible to modify waisindex so that it ignores files that
start with a dot (like the NeXT indexer)...

-- 
 | Paul Lindner | lindner@boombox.micro.umn.edu   | Slipping into madness
 |              | Computer & Information Services | is good for the sake
 | GopherMaster | University of Minnesota         | of comparision.
///// / / /    /////// / / / /  /  /  /   /      //// / / / /  /  /  /   /
Newsgroups: comp.infosystems.gopher
From: cameron@cs.sfu.ca (Rob &)
Subject: Forwarding links
Reply-To: cameron@cs.sfu.ca
Organization: SFU
Date: Wed, 19 Aug 1992 19:25:38 GMT

A severe problem is what to do when a gopher server is reorganized or
moved to a different machine.  Consider the problems arising from 
manual system administration based on comp.infosystems.gopher articles
such as:

> To any gopher admins pointing at sol.acs.unt.edu (this includes you, Ed! :-),
> place change your links to point at gopher.unt.edu instead as the server
> may (probably) move in the future.  My server is now patched to think it
> is gopher.unt.edu (thanks to the guy who showed me trick).

Why not make the idea of a "forwarding link" part of the Gopher protocol
so that access to an outdated link will:

  (1) still be allowed for a specified period of time,
  (2) automatically connect to the new host/file, and
  (3) send an e-mail message to the administrator of the source
      which was used to access the link (this would be a hidden function
      of gopher clients).  The format of this e-mail message should also
      be well-defined to allow a simple tool to update the appropriate
      link files. 


Rob Cameron                               cameron@cs.sfu.ca
School of Computing Science
Simon Fraser University
Burnaby, B.C.  V5A 1S6

Xref: sparky comp.infosystems.gopher:167 news.answers:2496
From: ullmer@uiuc.edu (Brygg Ullmer)
Newsgroups: comp.infosystems.gopher
Subject: Re: Personalizing gopherspace
Date: 19 Aug 92 14:04:32 GMT
Article-I.D.: news.Bt8HrM.6KD
Reply-To: ullmer@uiuc.edu
Organization: University of Illinois at Urbana
Originator: bau50671@uxa.cso.uiuc.edu

davet@granta.uchicago.edu (David Thomas) writes:

>Has anybody thought about changing the gopher clients (I'm thinking
>particularly about the curses and X clients, but it should presumably
>apply to the others) to do the following: Arrange that when the client
>starts, instead of contacting a server, it looks in say $HOME/gopher,
>and if it finds it, presents the data in the usual way.  

An implementation of this can be accomplished with fairly minimal modifications
to the bookmark facilities of the 1.0x Unix Gopher Clients... and I agree
that such provisions could be very useful.  I have thought of making such 
modifications to release with a collection of starter linkages through
GopherSpace targeted at different groups of people... for instance, linkages
oriented in nomenclature and content to children, homemakers, undergrads, 
business professionals, etc.

Brygg Ullmer
Newsgroups: comp.infosystems.gopher
From: tiktin@sisters.cs.uoregon.edu (David Mark Tiktin)
Subject: q type revisited
Organization: CS Dept, University of Oregon
Distribution: comp.infosystems.gopher
Date: Thu, 13 Aug 1992 18:33:16 GMT


About a month ago (?) there was a thread on alt.gopher about a q data type
which would allow servers to request that clients prompt users for data and
return that data with the selector.  I wanted to review this thread, so I
looked in U Minn's gopher news archive, but the postings from this thread seem
to be missing (why?).

Is there somewhere else I can look for these postings?  If other info (or
code) about the q type is avaiable somewhere, would someone post where I can
find it?

By the way, xgopher dies whenever I try to use it to retrieve the news archive
(too many entries?) but the unix client does it without any problem.

Thanks
tiktin@cs.uoregon.edu