Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!usc!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: <926@faatcrl.UUCP>
Date: 4 Feb 91 01:00:55 GMT
References: <1991Feb3.075026.1923@ckctpa.UUCP> <910203.083436@lerami.lonestar.org> <1991Feb03.221430.19135@hoss.unl.edu>
Organization: FAA Technical Center, Atlantic City NJ
Lines: 48

231b3678@fergvax.unl.edu (CS 231 section 2) writes:

>Here's a small list of the includes I'd like to see to jrcomm:

>1) In the file transfer window have % efficiency for transfer.

  Is this *really* neccesary?  You've already got a chars/sec.  I mean, do I
need to post every possible kind of stat that can be computed?

>2) Have a scratchpad so I can put all my miscellaneous stuff on it like
> 
>    :-) is a smilie
>    (402)421-1963  SWL BBS   6316 files!
>    Dr.Death is also known as Mr.Death
> 
>   Prefferably a huge screen of string gadgets (like the MACRO editor).
>   Pasting and clipping can be used with SNAP!!  :-)

  Clipboard support will be added.  As for this, it may be better to just save
this to a file and massage it into a script to load the macro keys (for the
1.1 version, which will have scripts).

>3) Have a complete status feature.  It keeps track of how many times
>   you've called a BBS, the number files you've up/downloaded from the BBS,
>   the files you transferred, 
>   the date and time you last called it, the length of the session, and the
>   accumulative total of your PHONE BILL!  Preferrably stuck in the phonebook,
>   like click the STATUS button and click the BBS you want info on.

  A complete call/usage tracking facility will eventually wind its way into
JR-Comm, doubtful for 1.1 though.

>4) Scripting (but who needs it!  If you're that despirate for script languages
>   just use NCOMM the few times you want to use it)

  Yep, 1.1 will have scripts and ARexx.

>5) Make the VIEW-buffer a task, so we can STILL scroll around in it
>   and read it s while we're up/downloading (Z-Term allows this! :-( 

  The 1.02 version will close the capture file prior to starting a file
transfer so that you can load it into the text reader of your choosing.  It
will also reopen the capture file (append mode) after the transfer completes.
Is that sufficient?  I can't see incorporating the code into JR-Comm for what
would essentially be my idea of a text reader, which is almost surely not your
idea of what one should be...

  -jack-