Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!pollux.usc.edu!papa From: papa@pollux.usc.edu (Marco Papa) Newsgroups: comp.sys.amiga Subject: Re: Atalk III & Kermit Message-ID: <27436@usc.edu> Date: 8 Oct 90 20:49:37 GMT References: <27412@usc.edu> <1990Oct8.193808.21972@ux1.cso.uiuc.edu> Sender: news@usc.edu Distribution: comp Organization: Felsina Software, Los Angeles, CA Lines: 30 Nntp-Posting-Host: pollux.usc.edu In article <1990Oct8.193808.21972@ux1.cso.uiuc.edu> jbn35564@uxa.cso.uiuc.edu (J.B. Nicholson) writes: >papa@pollux.usc.edu (Marco Papa) writes: >>Note that there is >>NO loss in performance by using the external XPRkermit compared to the built-in >>kermit, while this is NOT true concerning XPR-Zmodem vs. built-in ZMODEM, and >>that's why we'll keep the built-in ZMODEM. > >Why not fix the XPR Zmodem? > >I really like the idea of XPR, and I think, with the right set of XPR protocols, >you terminal developers could (theoretically) drop all transfer protocols and >concentrate on the terminal emulator side of the product. There is really nothing to fix. XPR-Zmodem has an inherent overhead due to the external protocol definition. This can be minimized with appropriate coding, but I doubt that it will ever be as good as a built-in one, where the extra overhead of procedure pointers and library calls is not there. I see the above being true of full-duplex streaming mode protocols like Zmodem and Ymodem-g, while pretty much ANY half-duplex protocol (like Kermit, Xmodem, and Ymodem) will not have any appreciable downgrading in an XPR implementation. -- Marco -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= "Xerox sues somebody for copying?" -- David Letterman -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=