Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uwm.edu!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!gvlf3.gvl.unisys.com!faatcrl!jprad
From: jprad@faatcrl.UUCP (Jack Radigan)
Newsgroups: comp.sys.amiga.datacomm
Subject: Re: Features I'd like to see in JRCOMM
Message-ID: <956@faatcrl.UUCP>
Date: 9 Feb 91 00:11:44 GMT
References: <1991Feb08.080428.19190@hoss.unl.edu>
Organization: FAA Technical Center, Atlantic City NJ
Lines: 51

231b3678@fergvax.unl.edu (Phil Dietz) writes:

>1)  Have a TURBO ascii send mode where it will not print the message you
>    are sending OR the messages sent from the machine you are sending it
>    to, until the transfer is done.  The only time text on the screen
>    will show is when the transfer is complete.  (Maybe have a little
>    ascii transfer upload status menu like Zmodem does)

>    REASON:  at a direct connect 19.2k
>    connection, uploading ASCII files (uue's) results in trashed files
>    a lot.  The buffer seems to be getting in the way and crapping the
>    transfer out (like it doesn't pick up the EOLN or something which
>    results like:

  It's not the buffer "getting in the way", it's most likely the fault of 
the remote system's editor or whatever than can't handle the speed of the
ASCII send as it is already.  Try using some character pacing or prompted
sends and I'd bet that it works fine.  Either that, or you've got some
kind of flow control problem.

>3)  Don't even think about stripping out your ZMODEM routines to replace
>    it with XPRZmodem!  XPRZmodem wreaks a big one!  Your zmodem
>    implementation is SO good, you should call it JRZmodem instead
>    of JRComm!

  You got that right!

>4)  Think about adding Chuck Forsberg's new Zmodem compression algorithms.
>    They just added it to UNIX rz/sz and MSDOS in the last month or two.

  Can't.  I already inquired about adding ZMODEM-90 extensions.  It seems
Chuck's gone off the deep end with his licensing policy of $80 per copy
sold.  $80 for about 3-5% increase in performance, jeez...

>5)  Have a FOLLOW mouse option.  Clicking on a spot will send the
>    appropriate cursor ups/lefts to get there!  Also allow changing of
>    cursor ups etc. to hjkl's for VI and EMACS!  This would be a
>    SMOOTH option!

  Not so sure about this one, too much room for errors if the remote system
can't handle the possibly huge amounts of ANSI sequences this could
generate.

  Besides, most editors have macro sequences that can get you there quicker
than the one-arrow-sequence multiplied by how far it has to travel.  Can you
imagine the delay it could take at 1200 or 2400bps from when you clicked on
the target location to when the cursor gets there?

  I'll end up getting flamed for that one too... <sigh>

  -jack-