Xref: utzoo comp.mail.misc:5454 comp.mail.uucp:6523 Newsgroups: comp.mail.misc,comp.mail.uucp Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!uupsi!schoff From: schoff@uu.psi.com (Martin Schoffstall) Subject: Re: BITFTP grief! Message-ID: <1991May17.202220.9531@uu.psi.com> Organization: Performance Systems International, Inc. References: <1991May16.145758.6817@uu.psi.com> Distribution: na Date: Fri, 17 May 91 20:22:20 GMT In article peter@ficc.ferranti.com (Peter da Silva) writes: > >"uux uupsi!rftp sprite.berkeley.edu:~ftp/mx.tar.Z (ficc!~/from-uupsi)" > >I realise this might hurt your flat rate pricing, so you could restrict Pricing is not an issue at all, actually, the only problems have been (a) admin overhead of people oriented things, (b) breaking mailers. >rftp to people with DCS or LAN-DCS access, or impose a surcharge, or >something. HOST-DCS and LAN-DCS already support anon ftp and tcp/ip so this isn't an issue. >Which requires interactive access to the Internet. When one is using an >intermittent transport mechanism (dial-ups and modems) a store-and-forward >technique is much more useful. With a smart enough UUCP on your end, you >could even avoid staging the file at all in most cases. Obviously you can have dialup Internet access today. What your really looking for is "batched XFtp" with last hop polling control. Which is even more general than your rftp. But lets go back to your rftp, what you need to do is create the code and make it work across 2 dozen platforms and it will be as explosive as CNews use. So get the community to work the spec and write the code and we're off, minimum portability would be bsd4.x sunos sysv xenix ice's Uaccess uupc aix Your biggest and most controversial design decision will be to decide if this works one hop or multiple hops. Marty