Comment 6 for bug 1272313

On Feb 04, 2014, at 09:38 AM, Matthew Paul Thomas wrote:

>If checking for an update is a multi-step process, that's excellent
>news, because it means the progress display can be determinate rather
>than just a spinner. Like the ability to stop, I guess that would
>require an extra dbus method to ask "how far through are you right now".
>Reported bug 1276061 for that.

The tricky part is that we won't know how many steps are involved ahead of
time. For example, let's say we have three of the four keys already when we
start the check. The first thing we do is download the blacklist, and if one
of the three keys is now on the blacklist, we'll have an extra step to
download a replacement. Also, it's possible that once we've downloaded the
first key, it might make subsequent key checks fail validation.

There's an upper limit to the number of things we have to download during the
check though, so we could just emit something like:

step 1 of 7
step 2 of 7
(steps 3-5 can be skipped so...)
step 6 of 7
step 7 of 7

It might make the display a bit jumpy, but it would be feasible without much
work. For backward compatibility we'd have to add new dbus signals for these
progress steps.