jmr wrote: > Brock Pytlik wrote: >> jmr wrote: >>> Brock - the first thing we do in the UpdateManager is get the list >>> of pkgs and state dic's that describe the packages using >>> img_obj.inventory(). As long as the data is available in the state >>> dic we can consume it. This would seem to be the right place to add >>> a reboot flag (could be an enum if there are a range of values based >>> on severity level). >>> >>> One issue I have at the minute is that the state dic contains an >>> incorporated flag which is great but its not updated so not so good. >>> If you just add a reboot flag to the state dictionary then we can >>> grab that too. This way the GUI's can leverage information coming >>> back from the API with minimal change. >>> >> I don't think this is a viable solution. I don't think I explained >> things clearly the first time, so let me try again. A package as a >> whole won't cause a reboot, a specific action within that package >> will. Whether or not that action is performed will depend on the >> version being upgraded from and to. So it doesn't make sense to make >> a package as reboot needed before the installation of that package >> has been evaluated. > Pity - would have been nice to surface this in the UpdateManager GUI. > One option would be to do the evaluate in the UMNotifier which runs > periodically in the background to check for updates, then cache this > data for the UM GUI to consume later on, would reduce startup and > allow us to notify the user about these issues. That would be fine by me. >> >> Also, encoding a particular implementation of Image.inventory() (or >> the implementation of its state dictionary) which escapes past the >> API is, imo, the wrong thing to do as its exactly things like this >> that have caused problems in the past. > That's just a workaround until we get the list of packages directly > from the API :) We agreed that this would not happen for the initial > release. ok :) Just wanted to be sure it wasn't what you were expecting to continue to get. >> >> More generally, that solution doesn't solve the problem of >> "installing these 6 packages will cause these 9 services to be >> restarted." The reason I'm a proponent of option 3 is that it allows >> us/package creators to add new services to be restarted without >> having to coordinate the change with the clients. When the clients >> are aware of specific actuators (I think that's the new term for >> things that let us know a reboot is needed, or to restart an smf >> service, etc...), they can notice a particular flag and present their >> UI accordingly. But, when a new flag is added they're not aware of, >> they can fall back to the string and severity level for a generic UI >> display. >> >> As a side note, if info is really slow because it's touching the >> disk, I can add a brief option, or a no-summaries option, or >> something like that so that the manifests (and the summaries) aren't >> retrieved from disk. Then the summary and size returned would simply >> be None. > Its the size we want :( Tends to be more relevant for updates for users. So how were you getting size quickly in the past? > [snip] >>> One other problem I have at the minute is fetching info objects from >>> the api is painfully slow. So for instance I'd like to display the >>> size of the packages to upgrade in the treeview, but it takes over a >>> second to fetch each info object to get this data from the manifest, >>> which is way to slow for us. At the minute I just hide the size >>> column and force the user to click on the row to get the details, >>> including size . Not ideal but workable atm. What we really need is >>> caching support on the client for the info objects and the >>> underlying manifest data. Other wise we will end up doing the >>> caching and that seems to be broken. >>> >> I would tend to say that caching information should be handled by the >> client according to their needs, since different clients might have >> vastly different cacheing protocols and needs, and to force a single >> one into the API, or make several available via the API seems the >> wrong direction to go to me. I'll admit I'm confused as to exactly >> what the problem is. I understand that info is slow since it must >> touch the disk to read the manifest, but how was that not the case >> before? Doesn't packagemanager currently have to read in each >> manifest from disk to get its summary and license anyway? I don't >> think the API should replace whatever cacheing system you were using >> to make that fast, I think it should replace those times when the >> package manager was directly reading the manifest from disk. > Well what would be nice would be to have pkg refresh take an optional > cache option so it would save off a single cache file of all the > manifest data that is in lots of separate files. Then when we have an > API to retrieve the inventory and with the existing one to get info > objects they could take a boolean option to retrieve it from the cache > or directly. That way you hide the details from the clients but make > fetching the manifest data a lot faster. Its up to the clients to make > sure refresh has been called with the cache option. > > If this isn't done we will end up generating a cache file using > UMNotifier to do the work and have the client consume it if its > available, but then we will have different code paths for consumig the > cache or the API info objects :( >
I feel reasonably certain this isn't code that should live within the API, but I could be convinced otherwise. I do think that adding this kind of cacheing into the API, would be a task that lived down the road. Also, if you wanted to, you could write the caching stuff inside the API, and use it as you wanted to, if you think it really belongs inside there. Personally, I think it's potentially dangerous to say things like "the client will always call refresh appropriately before looking at the cached data" without a programmatic way of enforcing such a constraint. Brock _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
