Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!gem.mps.ohio-state.edu!ginosko!uunet!crdgw1!crdos1!davidsen From: davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) Newsgroups: comp.mail.uucp Subject: Re: Zmodem added to UUCP Summary: good and bad ideas Message-ID: <517@crdos1.crd.ge.COM> Date: 26 Sep 89 12:33:07 GMT References: <3602@escargot.UUCP> <85418@pyramid.pyramid.com> Reply-To: davidsen@crdos1.UUCP (bill davidsen) Distribution: usa Organization: GE Corp R&D Center Lines: 25 In article <85418@pyramid.pyramid.com>, csg@pyramid.pyramid.com (Carl S. Gutekunst) writes: | If I understand this proposal correctly, what you have described is a way to | use uucico as a protocol selection frontend to the standard ZModem file trans- | fer routines. Likewise for XModem and YModem, yes? Zmodem is a good idea. It works well over links with long time delay for turnaround, allows restart of file transfers, works very well over packetized connections, and lots of good things. However, I can't think of a single instance in which Xmodem or Ymodem would provide any gain over existing protocols. If the idea is to allow connection to non-uucp programs, there are better ways to do it, such as using Kermit for a front end (I posted a program to do this to alt.sources recently). As an extension for use on dificult lines I like it, but there seems to be no benefit to adding X and Y protocols, which seem to perform worse than g under any typical conditions. I'm not in favor of "protocol clutter." -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) "The world is filled with fools. They blindly follow their so-called 'reason' in the face of the church and common sense. Any fool can see that the world is flat!" - anon