🚀 go-pugleaf

In article <Snews.960801.212604.chris.611@keris.demon.co.uk>
   Chris Croughton <chris@keris.demon.co.uk> writes:
> In article <31ff4c84.4247976@news.demon.co.uk>
>            robm@demon.net "Robert Mortimer" wrote:
> 
> >What would people like to see in it?
> 
> (...)
>
> Logging of any command to file (for instance asystat > x.log)

Definate "me too" on this one. A few others:

1) Improved nos.log logging. At present it seems to manage to log almost 
everything of no value, and nothing of any value. For instance, on loggin 
in we get: 

 -----8<-------8<-------8<-------8<-------8<-------8<-------8<-------8<-----

Sun Aug 04 13:05:28 1996 - sl0 dialer: init "AT&FX4L3&C1&D2\\V2\r"
Sun Aug 04 13:05:28 1996 - sl0 dialer: dial_cmd "ATDT"
Sun Aug 04 13:05:28 1996 - sl0 dialer: number "286666"
Sun Aug 04 13:05:28 1996 - sl0 dialer: retries 30
Sun Aug 04 13:05:28 1996 - sl0 dialer: control down
Sun Aug 04 13:05:28 1996 - sl0 dialer: wait 2000
Sun Aug 04 13:05:30 1996 - sl0 dialer: control up
Sun Aug 04 13:05:30 1996 - sl0 dialer: wait 2000
Sun Aug 04 13:05:32 1996 - sl0 dialer: init
Sun Aug 04 13:05:32 1996 - sl0 dialer: wait 3000 "OK"
Sun Aug 04 13:05:32 1996 - sl0 dialer: dial
Sun Aug 04 13:05:32 1996 - sl0 dialer: cwait 45000 "CONNECT" "BUSY" "NO CARRIER" "NONE" "VOICE"
Sun Aug 04 13:05:53 1996 - sl0 dialer: wait 60000 "ogin:"
Sun Aug 04 13:05:57 1996 - sl0 dialer: wait 1000
Sun Aug 04 13:05:58 1996 - sl0 dialer: send "holly\r"
Sun Aug 04 13:05:58 1996 - sl0 dialer: wait 60000 "word:"
Sun Aug 04 13:05:58 1996 - sl0 dialer: send "nearlyforgottochangethis\r"
Sun Aug 04 13:05:58 1996 - sl0 dialer: wait 60000 "otocol:"
Sun Aug 04 13:05:58 1996 - sl0 dialer: send "PPP,idle=0\r"
Sun Aug 04 13:05:58 1996 - sl0 dialer: wait 60000 "HELLO"

 -----8<-------8<-------8<-------8<-------8<-------8<-------8<-------8<-----

Everything there is already in my dialer - I *know* what I'm sending to 
Demon, what I want to know is what comes back! Connect information (from 
the modem), for example, and which machine/port I've connected to. Having 
the connect password stored in the log is particularly silly (and I 
nearly forgot to remove it before posting this).

In addition, results of FTP connections would be useful (ie throughput), 
etc. A quick browse through nos.log will show several things of no use 
whatsoever, and I'm sure many other d.i.d readers can think of things 
they'd like added. 

2) nntp trace - I'd find an option somewhere between "show article 
ID/group name" and "show everything" - show article 
ID/group/subject/author, for example. I maybe the only one who'd want 
this... 

3) Article ID display in event of nntp failure. At present we get the 
NNTP error code, but no indication of which article was being received 
at the time (since nntp verbose only shows the article ID after receipt, 
that doesn't help). This would be very useful in the event of corrupt 
articles (and should be included in nos.log - see (1)). An alternative 
would be to display the article ID being received rather than waiting for 
receipt of it to complete.

4) SMTP LIST - abbreviated mode. When sending mail to a large number of 
recipients (ie several addresses in the .wrk file) KA9Q insists on 
showing them all when "smtp list" is issued, or when it starts sending 
them. This is a common problem for those running mailing lists - each 
article can easily require a screen or more to display, so any usefulness 
is lost because most of the information scrolls off screen. Displaying 
the first ID with "..." tagged on the end would be great.

5) Following on from (4), I understand that KA9Q stores the list of mail 
recipients in memory rather than reading them on-demand from the .WRK 
file, resulting in an inability to cope with mail to more than a certain 
number of recipients at once (presumably memory limited). If KA9Q didn't 
need to read the full list for display purposes (see (4)) there's 
presumably no reason why the bulk of the .WRK file couldn't be read when 
needed, and the interim memory saved? 

6) Option to limit history file size, preferably on loading. That is, as 
the file is loaded, everything over (say) 1000 lines results in the first 
stored history article being dropped from the list before the new is 
added. New articles are then added to the list on reciept without tailing 
the history file further, and the new (shorter) list written to disk on 
completion. I'm not sure how feasible that would be; perhaps best left to 
external utilities (I do this already, and KA9Q generally behaves better 
for it, IME).

7) An option for an alternative "ftp hash" which simply displayed 
"\rBytes received: %d". Thought should also be given to how "ftp hash" 
results (both as at present and as suggested above) gets written to 
"record"ed files. IMHO the hashes should not be logged at all.

8) An option to set a "tab size" parameter in KA9Q, and have tab 
characters thus expanded. status@gate is much better than it used to be, 
but a way of handling tabs properly would be useful. 


Thoughts?

Obviously memory requirements are an important consideration, and 
conversion to protected mode is really the only way around that. In fact, 
the only way for KA9Q to survive for much longer will be with a PM 
version so that new features can be added to it (like a lynx viewer, 
etc). 

Mark.
-- 
int MeaningOfLife (void) { return 42; }   // mcr@holly.demon.co.uk
function MeaningOfLife :integer; begin MeaningOfLife := 6 * 9 end;