Xref: utzoo comp.mail.misc:5479 comp.mail.uucp:6563 Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!zaphod.mps.ohio-state.edu!mips!dimacs.rutgers.edu!rutgers!njin!uupsi!ficc!peter From: peter@ficc.ferranti.com (Peter da Silva) Newsgroups: comp.mail.misc,comp.mail.uucp Subject: Re: rftp (was Re: BITFTP grief!) Message-ID: Date: 19 May 91 16:18:36 GMT References: <1991May16.145758.6817@uu.psi.com> <1991May17.202220.9531@uu.psi.com> <-=DB8WF@xds13.ferranti.com> Reply-To: peter@ficc.ferranti.com (Peter da Silva) Organization: Xenix Support, FICC Lines: 33 In article 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?"