Date: Fri, 14 Aug 92 16:38 EDT
From: Joy.Lynam@MVS.UDEL.EDU
Original-To: gopher-news@boombox.micro.umn.edu
Subject: Using mail to provide gopher data
Newsgroups: comp.infosystems.gopher
Distribution: comp

We do as Brad suggests in his message below ... we use email to load gopher
data. It's familiar, easy, and users don't have to learn Unix. They just mail
their gopher data to an id on our gopher server. Basically, what we do
is........

--Make user name (UniqueID) on gopher server for each 'application' or
  type of gopher data.
--Users send messages containing their gopher data to UniqueID@GopherServer.
--At night, we open the mail file and extract those messages by UniqueID.
  We throw away mail header, subject becomes filename, and message is written
  to a directory associated with that UniqueID. Messages with same subject are
  either overwritten -or- an entry is added to a link file with a uniquely
  generated filename (format: .name) and message is saved in a file with
  that unique ".name".   Mail subject becomes "Name" in link file, so
  duplicates are allowed.
--We encourage authentication for each directory, at least one or two names.
--Users can delete messages by using our unique delete string as first line of
  message.
--To change gopher data, users use the Unix client mail feature to mail the
  message to themselves, change it, and mail it back to UniqueID.

This method as been a good way for us to use a common application (mail) to
distribute the job of loading gopher data.  And, users can own and
maintain their data.  We've just begun doing this so we it's not refined.
But we think we it's a great idea.

Delaware's "U-Discover" Gopher is available through Michigan's other gopher
servers or at lobster.mis.udel.edu 70.

Joy Lynam / University of Delaware
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
> To: gopher-news@boombox.micro.umn.edu
> From: Brad Clements <BKC@draco.erc.clarkson.edu>
> Date: 7 Aug 92 16:05:41 EDT
> Subject: Gopher Server NLM for Novell NW386, anyone want one?
>
> In our environment, we have many administrative departments with Novell
> or VM/CMS access. None of these users know a thing about Unix. Although we
> are running a Unix gopherd, I couldn't imagine having any secretary try and
> add a new directory entry or update a file. Yes I could write scripts to
> do this for them, but they'd still need accounts, would still need to login,
> and would still have to FTP the file from their PC to the system.
>
> Neither do we have the manpower to update and maintain all this information
> ourselves. We could set up some kind of mail processor which would accept
> info from users, authenticate it and update it, but the user still must
> `have a brain'.
>
> ---
>
> I could easily write a Clarion/Paradox/Btrieve (or whatever) application whi
> presents the info-base in the same hierarchy that gopher returns, allows the
> user to insert and move information around, and updates a database that
> a Novell NLM gopher would access. Wais indexing could probably also be
> ported to this environment (depending on its VM requirements).
>
> Also, we could fully utilize the access control provided by Novell, eliminat
> and extra step of authorization/login.
>
> Or, I could write a stand-alone dedicated DOS box gopher server to do this,
> but I don't think the performance would be nearly as good as running on the
> server.
>
> ---
>
> So, does anyone have any comments about this scheme? Don't put it down
> just because you think it might be too slow, you'ld be surprised how fast
> TCP on NW386 really runs, and the disk access is MUCH faster than most Unix
> systems (properly configured server, of course).
>
> ---
>
> The objective is to provide an environment where the originators of the data
> need only work in a familiar environment which is integrated with the source
> of the information.
>
> Thanks for any comments,
>
>
> |Brad Clements, CCP        bkc@draco.erc.clarkson.edu      (315)268-2292
> |Sr. Network Engineer      Clarkson University             Potsdam, NY USA