lynx-dev
[Top][All Lists]
Advanced

[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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]