Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!samsung!sol.ctr.columbia.edu!ira.uka.de!math.fu-berlin.de!ox.com!msen.com!emv From: emv@msen.com (Ed Vielmetti) Newsgroups: comp.mail.misc Subject: Re: BITFTP grief! (UUNET email-ftp?) Message-ID: Date: 22 May 91 20:56:51 GMT References: <81678@bu.edu> <4068@island.COM> <1991May22.081251.1026@uunet.uu.net> <1991May22.174325.6230@chinet.chi.il.us> Sender: usenet@ox.com (Usenet News Administrator) Organization: MSEN, Inc. Ann Arbor MI Lines: 33 In-Reply-To: les@chinet.chi.il.us's message of 22 May 91 17:43:25 GMT In article <1991May22.174325.6230@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: How do you feel about requests like checking the directory of the test versions of kermit on watsun.cc.columbia.edu on a weekly basis? Les, If you can specify exactly where the files you are interested in are, it is straightforward to maintain a reasonably up to date shadow directory of the remote FTP site and make that directory available for UUCP. Updates can be handled in a number of ways - triggered by references of new versions in comp.archives - refreshed on demand by users who make a request like rftp -dir watsun.cc.columbia.edu:/kermit/test/ ./kermit-test-dir.out to see what's out there - kept up by hand by humans if there's something amiss - automatically shadowed weekly or every n days according to need - changes noticed whenever "archie" updates are done Naturally you'd like to keep whatever mechanisms there are for making sure that the file you fetch is the same as the latest version on the server somewhat hidden from the general "rftp" user, so that your caching will have a reasonable chance to work. No sense in going off to bother Columbia if you have a copy handy that's the same as what they have. UUNET has the "kept up by hand" part down pat, and I believe they have some automatic shadows running. There's a site in Australia that's caching based on comp.archives. Other schemes have been proposed as well. --Ed