You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Description of feature request:
For large downloads an interactive client would typically want to provide progress information (progress bar or just a running percentage or count of bytes). tuf.Updater could provide functionality that enables this.
The practical case I'm looking at is pip which currently uses the progress module while downloading chunks with requests module. If tuf support is added to pip, it will lose the progress indication functionality.
Current behavior:
The downloads are done in chunks already but there does not seem to be any way to add hooks into the download loop.
Expected behavior:
Updater could e.g. call an optional hook function with some progress data periodically. At a minimum the number of bytes downloaded so far should be available.
Thanks for the great feature request, @jku! Let me cross-reference with this general updater stack clean-up issue (#841) and another issue that touches the networking aspects (#932).
A large download at 50b/sec seems to mean one progress update every two hours which would not be very interactive.
Of course the values also mean that a server sending a large file 1 b every 4 seconds would only get flagged as slow retrieval attack after 18 days of downloading... so maybe these values could be re-evaluated anyway.
Activity
lukpueh commentedon Jun 29, 2020
Thanks for the great feature request, @jku! Let me cross-reference with this general updater stack clean-up issue (#841) and another issue that touches the networking aspects (#932).
jku commentedon Jul 2, 2020
When/if this is fixed, the default download settings should be re-evaluated:
A large download at 50b/sec seems to mean one progress update every two hours which would not be very interactive.
Of course the values also mean that a server sending a large file 1 b every 4 seconds would only get flagged as slow retrieval attack after 18 days of downloading... so maybe these values could be re-evaluated anyway.
Joshua pointed out #932 as related
jku commentedon Nov 13, 2020
This would be deprecated with #1213 updater: abstract out the network IO
joshuagl commentedon Apr 7, 2021
Resolved obsolete by #1213