[packagekit] Cache up-to-date-ness and bad user interation

[Hedayat Vatankhah]

  Hi,

/*Richard Hughes <hughsient at gmail.com>*/ wrote on 10/28/2010 1:07:05 PM 
+0350:
> At the moment we have the following mechanisms:
>
> RefreshCache  ==  download all different cache files from the remote repo
> GetUpdates  == get the list of updates from the packaging system, and
> /sometimes/ get the latest list from the server.
> SearchFile == search local or remote stores and maybe get new repodata
> if the metadata doesn't match the filelist
>
> I say sometimes, because yum has a built in "this is fresh enough"
> value, and so doesn't get the repodata from the server if the "fresh
> enough" value is less than the age of the updates file. The fudge
> value is sub-optimal.
>
> Of course, this has the effect of some update checks taking a few
> hundred ms, and some update checks taking a few minutes. This blows
> goats from a user interface point of view, as of course when we do the
> scheduled update check in the background we want to get the latest
> data from the repo, and when we do it in the GUI updater program we
> want to return results as quick as possible. Ideally we would want to
> specify the "this is fresh enough" value to the GetUpdates method.
I completely agree, being annoyed a lot from this kind of behavior, 
which led me to try running "yum -C" commands in many cases instead of 
using any other methods.

> Now of course, other methods are affected too. yum also downloads new
> primary and filelists data if the user does a command not found type
> action. Of course, we can give the backend hints about whether this is
> interactive or not-interactive (using SetHints) but I'm not sure if
> that's enough. All the backends seem to treat cache age slightly
> differently, which makes it even harder to design a GUI that's
> predictable.
>
> So, 4 ideas:
>
> 1. All transactions do not refresh data from the network, and work
> from a cache, no matter how old. If the cache is not available, then
> they can download data. The only time new metadata is downloaded is
> when the RefreshCache method is called, and this refreshes everything.
> Advantages: Allows us to get rid of the different "Check for updates:
> daily" and "Refresh package lists: weekly" UI entries.
> Disadvantages: All the metadata is downloaded every day, which is
> significant if you're on a mobile broadband connection, or a modem.
>
> 2. A new parameter to SetHints() which would be "cache-age=<time in
> seconds>". This would allow the frontend to encode how fresh it wants
> the data.
> Advantages: Allows fine control of the age of the returned results
> Disadvantages: Means the frontend probably has to query the updates
> check value and pass it this value for GetUpdates, and choose
> something sane otherwise. Most clients will set this to "intmax" which
> will mean "never". Backends will have a complicated set of behaviour
> where they have to juggle policy for cache-age, background and
> interactive.
>
> 3. A new formal policy, which says "interactive=TRUE always has to
> work from a cache where possible (unless specified for RefreshCache of
> course)"
> Advantages: allows GUI tools to get the results quickly, and
> introduces no new complexity.
> Disadvantages: We still have to encode a hardcoded value of cache-age
> for the non-interactive case. The user has no way to get the latest
> updates from the gui update viewer tool, until the next background
> update is specified. This is probably okay, as the interaction
> designers at Red Hat hate waiting for progress bars.
>
> 4. A combination of  "interactive=TRUE always has to work from a
> cache" and adding "cache-age=<time in seconds>" for !interactive.
> Advantages: Allows us to get the minimum amount of data, as we can use
> the update check frequency for GetUpdates.
> Disadvantages: lots of encoded policy which is getting pretty hard for
> backends to understand.
>
> At the moment I'm not sure which is my favourite, but this mail is
> designed for people to tear apart my ideas, and suggest better ones.
> I've got a feeling apt already works like idea 1.
I think the ideas are listed in the reverse order of my preference! :P 
The only extra thing which could greatly improve the user experience 
which comes into my mind is optimizing the back-ends themselves to use 
the available bandwidth much more optimally. I hope to start working on 
that for yum ASAP...

Thanks,
Hedayat

> Suggestions?
>
> Richard.
> _______________________________________________
> PackageKit mailing list
> PackageKit at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/packagekit
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/packagekit/attachments/20101030/b437cba8/attachment-0003.htm>