[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: lynx-dev [PATCH 2.8.3.dev4] More verbose transfer stats
From: |
Ilya Zakharevich |
Subject: |
Re: lynx-dev [PATCH 2.8.3.dev4] More verbose transfer stats |
Date: |
Fri, 23 Jul 1999 23:42:40 -0400 (EDT) |
>> This patch
>> a) makes size/transfer rate reports use format "8.3 KB" (instead
>> of "8 KB") if numbers are below 10 KB and reports are in KB;
>> b) makes transferred/expected/transfer-rate use bytes/KB independently
>> so "236 bytes of 56 KB" is possible, as is
>> "8.3 of 56 KB, 456 bytes/sec";
>> c) adds "ETA 23 sec" info if available;
>> d) adds " (stalled for 75 sec)" info if available (updated each 5
>> sec or so);
>> e) uses gettimeofday() if present (instead of current hacks) to get more
>> frequent updates.
>Btw. even if you care for all this additional info: the data it's based
>in is quite unreliable / arbitrary. It doesn't count all bytes in
>a HTTP message. It is undefined where in the byte stream counting starts.
>It is undefined where timing starts. See HTTP.c, where the first
>block(s) read may be handled differently.
>
>The total length is counted differently than the current length. To be
>comparable, start of counting should be triggered (or reset) in HTMIME.c,
>after the HTTP header has been parsed.
>
>Temporarily suspend a loading-in-progress (^Z, or possibly ESC key may
>do that; or try a binary type and wait a bit till you answer the 'download
>or cancel prompt'), and the numbers are meaningless.
>
>So this gives the impression of exact numbers, but it's misleading.
Definitely there may be many improvements to the way Lynx operates.
However, note that *all* the remarks you did are orthogonal to the
patch I sent: they are applicable as much with the patch as without
the patch.
>For my taste, it also reminds to much of Netscape...
Well, I see no shame in borrowing *good* user-interface decisions.
Ilya