NetNews Usenet Archive 1992 #27/NN_1992_27.iso/spool/comp/infosyst/gopher/1262

Text File | 1992-11-19 | 3.4 KB | 70 lines

Newsgroups: comp.infosystems.gopher
Path: sparky!uunet!cs.utexas.edu!usc!cheshire.oxy.edu!rafetmad
From: [e-mail] (David Giller)
Subject: Re: Expiring information ???
Message-ID: <[e-mail]>
Organization: Occidental College, Los Angeles, CA 90041
References: <[e-mail]>
Date: Fri, 20 Nov 1992 08:30:24 GMT
Lines: 59

[e-mail] (Kirk) wrote:
>G'day,
>     I am currently involved in setting up a gopher server on campus here at
>The University of Wollongong and was wondering if anyone knows of a way of
>setting expiry times on files or links withing gopher. The idea we have is
>that when links or information is added to the gopher server they can be
>given an expiry. When this expiry time is reached the information is removed
>and the owner of the files is notified by mail although the notification is
>really only the icing on the cake.
>
>Does anyone know if this is part of or planned for gopher ?  Maybe someone
>has written something similar themselves, I would be interested to hear.

I am in the process of doing this for a gopher-based campus-wide info
system in perl here at Oxy.

The system (tentatively called gopher-mh) will sit on the end of a
sendmail-style .forward file, and receive mail.  It will take incoming
mail, and based on the To: field, place mail in an appropriate gopher
directory.  We have several mailing addresses aliased to this account,
one for each area.

This, in effect, becomes a mini-news system for local information.  We
have, for starters, for-sale, items wanted, jobs available, and event
notices areas to which anyone can post.  I am looking into the
possibilities for more secure areas... that is, I'd like some method
of restricting WHO can post, without restricting from WHENCE they can
post.  We are attempting to make all services available to people
without ever logging into our UNIX hosts, I.E. from Mac- and PC-based
client software.

I am currently handling the expiration by creating a subdirectory in
each managed gopher data directory much like the .cap directory, but
called ".expire".  In it, each file which is to have an expire date in
the data directory has a file with the same name, in which is a date
in perl 'time' format, after which the file becomes digital history.

Now, the NOTICE:  This software is NOT DONE.  I am changing my mind
daily as to how and what it does.  So PLEASE don't write for more
info... I am NOT releasing this code now, and probably not for a good
while.

On the other hand, I am certainly open to suggestions, and should the
system prove useful in the general sense, I will certainly offer it to
the general gopher-using public.  In particular, I'd like to hear
suggestions on how to handle special options in the text, like
changing expiration dates and, perhaps, sending commands to delete
files before their expiration date, that can be understood and dealt
with by even a complete neophyte.  The single overriding goals in all
our systems is that they be extremely simple and intutive to use for
even completely novice users, and that they be as self-maintaining as
possible.

-Dave
--
David Giller, Box 134 | Q: How many Oregonians does it take to screw in a light
Occidental College    | bulb?  A: Three.  One to replace the bulb, and two to
1600 Campus Road      | fend off all the Californians trying to share the
Los Angeles, CA 90041 | experience. [e-mail]