On Sat, 27 Apr 2019, Timothe Litt wrote:

Thanks for your reply!

> I think I want to know about the outliers/problems, not so much the
> successful transfers.
>
> How about at least #failed transfers?  That would fit on a 1-line status.

But what are you going to use that info for? So in my example case, there
could be a few transfers that returned a failure but since the other transfers
aren't done yet you probably wouldn't stop the transfers anyway. Or am I
wrong?

Perhaps we should output to the screen if an individual transfer fails, like
"transfer of $URL returned XX: bla bla bla".

> # stalled (no data sent/received in - pick a threshold, say 5 secs?) could
> be helpful

What would anyone do with that information during transfer?

> The issue with "speed" is that while it tells you about curl's performance,
> what a user wants to know is what needs attention - which transfers are NOT
> making progress, or are slow relative to the pack e.g. (where picking a
> different mirror might help).

If that would be an issue and you want that control and the ability to stop
the transfers and switch source etc, it seems like an odd choice to do several
transfers in parallel then doesn't it?

>> o percent download (if known, which means *all* transfers need to have a
>> known size)

> The more files are involved, the greater the chance that at least one
> doesn't have a known size.

Absolutely!

> Why not compute the statistic for all the transfers that do?  Then add an
> asterisk
>
> DL%
>
> 42*
>
> * Excluding 17 transfers whose size is unknown (or not yet known)

Because it would be totally meaningless. What does 42% mean if it only is 42%
of N and we *know* that N is not the total amount.

> How about a curses interface?  That would give you a status window where you
> can put detailed information on each transfer - perhaps just one line each. 
> curses windows can randomly update & can scroll, so you can have an
> "unlimited" list. 

I'm not dismissing that idea, and perhaps that is the most sensible option in
the end, but that feels like a too big of a project for me personally to
undertake. If someone else wants to experiment with that, then please feel
free to do so.

> If you  are unwilling to require curses support, another approach is to
> build a status page as described, and define an key to print it.  So instead
> of continuously updating status, you get a detailed dump when you press a
> key (say space).

Oh yes, that's pretty neat idea!

-- 
  / daniel.haxx.se

-----------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-users
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2019-04-28