Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!uoft02.utoledo.edu!desire!arc
From: arc@desire.wright.edu
Newsgroups: comp.sys.amiga
Subject: Re: JR-Comm 1.10 Features
Message-ID: <1054.26cdefd9@desire.wright.edu>
Date: 19 Aug 90 06:48:09 GMT
References: <ias3N10w162w@valnet.UUCP> <72@faatcrl.UUCP>
Lines: 64

In article <72@faatcrl.UUCP>, jprad@faatcrl.UUCP (Jack Radigan) writes:
> joseph@valnet.UUCP (Joseph Hillenburg) writes:
> 
>>1) 2.0 compatibility - Reason: I don't want to pick up a new copy of 
>>JR-Comm, tehen have it break when I get OS 2.0.
> 
> Will have it with 1.01.
> 
>>2) ARexx - Reason: Why not?
>>3) Scripts -Although, if ARexx is properly implemented,  this won't be 
>>neccesary.
> 
> Probably for 1.2.
> 
>>4) XPR support.
> 
> Definately for 1.1.
> 
>>5) IBM Color and Mono wrapped up into one.
> 
> Are you refering to 16 colors w/blinking attribute?  If so, maybe in the
> future, but not now.  If not, what are you refering to?
> 
>>6) The following XPR protocols: XPRxmodem, XPRymodem, XPRzmodem, 
>>XPRjmodem, XPRkermit, XPRascii, XPRSealink(?), and XPRsadie.
> 
> I'll put the hooks in there for XPR, but I won't be writing the XPR modules
> except for the CIS B+ one since I'll be removing that protocol from the 
> program.  As for ZMODEM, an XPR module could never acheive the throughput
> that the internal code gets, so that will remain internal.
> 
>>7) Less "undesirable features". (bugs)
> 
> This goes without saying...
> 
>>Circumstances prevent me from mailing John (Jack?) Radigan a registration 
>>form. J.P. Radigan, if you are reading this, please send me a form. I 
>>would gladly register if you did. (My PaintJet is in the Shop).
> 
> Ok, will do.
> >   -jack-

   Jack, I have used your JRComm for a while now, and find it very nice.  About
the internal ZModem, I don't find it that efficient...  I have used NComm 1.9
with it's external ZModem, and it takes MUCH less CPU time (I used XOper, plus
by doing some mtasking, etc.) for all xfering.  I run your term at a 0
priority, just as I do NComm 1.9 (NComm 1.9 is buggier than JRComm 1.0), but
the Zmodem library does an AWSOME job.  I will be uploading with JRComm 1.0 at
a 0 priority (on its own screen) and then when I go to resize a window on my
workbench screen (interlaced) your term pause the transmit for a split
second...  This really bothered me that you'd say that an external ZModem
wouldn't achieve the thoughput that your internal does...  It's a fine program,
and I would VERY much like to send in my donation and registration...  I don't
know, maybe I'm asking too much?  Think so?

 
------------------------------------------------------------------------
=    ///           | Jim Perry                 | Arc@Desire.Wright.edu =
=   /// Amiga!     | ^Communications Consultant|         -or-          =
= \XX/ The One     | Arc Electronics, Inc.     |    Arc@WSU.BITNET     =
= ____& Only...    | Wright State University   |"Ouch! Quit-it." - Bart=
=                  | Dayton, Ohio              |  Frank Sinatra Rules  =
========================================================================