On Tue, 15 Sep 2020 11:44:07 -0700 Jacob Keller wrote: > Exactly how I saw it. > > Basically, the timeout should take effect as long as the (component, > msg) pair stays the same. > > So if you send percentage reports with the same message and component, > then the timeout stays in effect. Once you start a new message, then the > timeout would be reset.
I don't think I agree with that. As I said that'd make the timeout not match the reality of what happens in the driver. Say I have 4 updates (every 25%) each has a timeout of 30 seconds. If I understand what you're saying correctly you'd set a timeout of 2 min for the operation. But if first two chunks finish in 10 seconds, and 3rd one timeouts out the timeout will happen (in the driver) when the user-visible timer is at (50sec / 2 min). I think that each notification should update the timeout. And like systemd we should not display the timeout counter in the first, say 5 seconds to minimize the display noise. > We could in theory provide both a "timeout" and "time elapsed" field, > which would allow the application to draw the timeout at an abitrary > point. Then it could progress the time as normal if it hasn't received a > new message yet, allowing for consistent screen updates... I'm not sure I follow this part. > But I think that might be overkill. For the cases where we do get some > sort of progress, then the percentage update is usually enough.
