Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!elroy.jpl.nasa.gov!ncar!gatech!rutgers!faatcrl!jprad
From: jprad@faatcrl.UUCP (Jack Radigan)
Newsgroups: comp.sys.amiga.datacomm
Subject: Re: Even MORE features to add to JRCOMM
Message-ID: <982@faatcrl.UUCP>
Date: 13 Feb 91 19:00:52 GMT
References: <9102130227.AA20204@bisco.kodak.COM> <1991Feb13.033400.21259@hoss.unl.edu>
Organization: FAA Technical Center, Atlantic City NJ
Lines: 21

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

>ps.  I kinda like the requester JRCOMM has.  It has that neat and quick 
>     button that allows you to QUICKLY switch to an assigned drive, 
>     a drawer, or a mounted device easily.  If Jack would incorporate
>     a BUFFERED option, the requester would be perfect.  True, the argument
>     takes precedence about how JRCOMM EATS memory, but when XPR is added,
>     and all the pud protocals taken out, the added buffer option should
>     still make the executable smaller then before XPR and buffered stuff
>     was added.

  Well, there is only one protocal that's going to be moved out, CIS B+.
It does take a good chunk of code with it, about 10-15k.  But, the XMODEM
series of protocols all use a good portion of the same code, each one does
not use it's own code, only ZMODEM does.  And that will *not* be relocated
to an XPR module, I'd lose too much performance if I did.

  I do like my file requester (IMHO) and may make it a req.library type of
thing, but that would depend on the demand it receives.

  -jack-