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