<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html; charset=UTF-8" http-equiv="Content-Type"> <title></title> </head> <body bgcolor="#ffffff" text="#000000"> Hi, <style type="text/css">blockquote {color: navy !important; background-color: RGB(245,245,245) !important; padding: 0 15 10 15 !important; margin: 15 0 0 0; border-left: #1010ff 2px solid;} blockquote blockquote {color: maroon !important; background-color: RGB(235,235,235) !important; border-left-color:maroon !important} blockquote blockquote blockquote {color: green !important; background-color: RGB(225,225,225) !important; border-left-color:teal !important} blockquote blockquote blockquote blockquote {color: purple !important; background-color: RGB(215,215,215) !important; border-left-color: purple !important} blockquote blockquote blockquote blockquote blockquote {color: teal !important; background-color: RGB(205,205,205) !important; border-left-color: green !important}</style>Richard Hughes <a class="moz-txt-link-rfc2396E" href="mailto:hughsient@gmail.com"><hughsient@gmail.com></a> wrote on 10/28/2010 1:07:05 PM +0350: <blockquote style="color: navy; background-color: rgb(245, 245, 245); padding-left: 15px; border-left: 2px solid rgb(16, 16, 255);" cite="mid:AANLkTi=tM7MVq9smppuuuVpx44KNgDURVGGD0gxb_Ay3@mail.gmail.com" type="cite"> <pre wrap="">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. </pre> </blockquote> 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. <blockquote style="color: navy; background-color: rgb(245, 245, 245); padding-left: 15px; border-left: 2px solid rgb(16, 16, 255);" cite="mid:AANLkTi=tM7MVq9smppuuuVpx44KNgDURVGGD0gxb_Ay3@mail.gmail.com" type="cite"> <pre wrap="">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. </pre> </blockquote> 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 <blockquote style="color: navy; background-color: rgb(245, 245, 245); padding-left: 15px; border-left: 2px solid rgb(16, 16, 255);" cite="mid:AANLkTi=tM7MVq9smppuuuVpx44KNgDURVGGD0gxb_Ay3@mail.gmail.com" type="cite"> <pre wrap="">Suggestions? Richard. _______________________________________________ PackageKit mailing list <a class="moz-txt-link-abbreviated" href="mailto:PackageKit@lists.freedesktop.org">PackageKit@lists.freedesktop.org</a> <a class="moz-txt-link-freetext" href="http://lists.freedesktop.org/mailman/listinfo/packagekit">http://lists.freedesktop.org/mailman/listinfo/packagekit</a> </pre> </blockquote> </body> </html>