emv@ox.com (Ed Vielmetti) (05/18/91)
> hypothetical rftp program
As an internet service provider, I would like to have this rftp
service available to MSEN customers. It would seem to dovetail quite
nicely with comp.archives, since there's all that verified location
information sitting there right handy to be used.
The spec should cover at least the following:
- format of remote files (e.g. sprite.berkeley.edu:/mx.tar.Z)
- specification of alternate delivery mechanisms, e.g. uuencoded and
mailed, queued at some grade for delivery, immediate call-back, left
in a spool to be picked up later.
- action to take on error (do nothing, do an archie search, do a
comp.archives search)
- mirror site treatment -- if someone fetches a file from the
australian simtel20 archive, it should be OK to pick that file off
your local disk if you are a mirror site or if your cache is
correct.
- package specifications -- if you have the comp.archives catalog at
hand, you should be able to ask for "mh" and get back the right thing.
- verification and limiting -- remote sites need to be able to see
what they are going to be getting to make sure they have enough disk
to handle it, and put limits so that request of over 5M
(accidentally perhaps) could be flagged.
Further input is encouraged; to get it right there's a lot of details
to attend to.
The "MSEN Archive Service" addresses just these sorts of needs; I know
just about exactly what I want to do, just waiting on some agreements
to be made and on sufficient resources to make them happen. Working
on a writeup of what it'll look like, will post when that's ready.
--
Edward Vielmetti, moderator, comp.archives. emv@msen.com
comp.archives is a production of MSEN Inc. peter@ficc.ferranti.com (Peter da Silva) (05/19/91)
In article <EMV.91May18124540@poe.aa.ox.com> emv@ox.com (Ed Vielmetti) writes: > > hypothetical rftp program > The spec should cover at least the following: > - format of remote files (e.g. sprite.berkeley.edu:/mx.tar.Z) It would have to be in native remote-system format. If that's not UNIX format a local file name would have to be provided. Wildcards could be used for systems that support "mget". It may be that there is sufficient variation in FTP systems that this would require the user to provide an FTP script. uux - uunet!rftp ~/from-uunet OPEN sprite.berkeley.edu CD ~ftp GET mx.tar.Z mx.tar.Z QUIT > - specification of alternate delivery mechanisms, e.g. uuencoded and > mailed, queued at some grade for delivery, immediate call-back, left > in a spool to be picked up later. So long as the host running the service can disable any of these. The "mirroring" and archie-search stuff implies a fair amount of smarts from this server. I would hope a dumb server would be made available when you know you're getting something not part of an official archive (alpha software, for example). That sort of thing is where normal archive access really falls down. But don't let this stand in the way of your more aggressive project. -- Peter da Silva; Ferranti International Controls Corporation; +1 713 274 5180; Sugar Land, TX 77487-5012; `-_-' "Have you hugged your wolf, today?"