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. 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. What do you think? JR for pkg, state in sorted(image_obj.inventory(all_known = True)): while gtk.events_pending(): gtk.main_iteration(False) if state["upgradable"] and state["state"] == "installed": pkg_upgradeable = pkg if not state["upgradable"] and image_obj.fmri_is_same_pkg(pkg_upgradeable, pkg): count += 1 # XXX: Would like to caputre if package for upgrade is # incorporated, could then indicate this to user # and take action when doing install to run image-update. if state["incorporated"]: incState = "Inc" else: incState = "--" Brock Pytlik wrote: > After talking with Bart this morning, I think we probably need to make a > small change to the API structure. > > He pointed out that, shortly, we'll have a way of detecting when a > reboot is needed to install a package, and installing it in an alternate > image (if I understood him correctly), but there's currently no way of > returning that information out past the API. He also suggested having > way giving general messages to the users so that changes made behind the > API which have UI implications can be passed on automatically to the > clients without making them sync up. > > In general, I think the solution is to either change what plan_X > returns, or add it to the plan description. In addition, I think we > might want a way to hand back information for the user after execution. > The situation I'm thinking of goes roughly like this for the gui: > Uses tries to install package Foo. > Packagemanager plans the install and notices that a reboot will be > required and informs the user of this. > User clicks ok, and the installation happens > After installation, packagemanager shows a reminder to the user that > they'll have to reboot in order to use this new package > > I think there are two design issues: where to pass the data around; what > data to pass around. > > For the first, I think the right answer is to include it in the return > values from plan_X and execute_plan, but I could be convinced the client > should get it instead when asking for the plan description. > > As for the second issue, I've imagined three broad approaches. > 1) Return a list/set of flags (like RebootNeeded) possibly along with > their severity. I'm imagining 3? levels of severity, 3: very dangerous, > used when a user is trying to do something we know to be bad (like > creating an image at /); 2: caution: used when something out of the norm > will happen, like a reboot being needed; 1: informational, other > information which might be desired. > 2) Return a block of text or a list of strings possibly along with a > severity which should be presented to the user before proceeding. > 3) A combination of 1 and 2. Return a list of flag, string, severity tuples. > > The advantage of 1 over 2 is that the UI has more freedom for choosing > how to present the user with information. The disadvantage of 1 is that > it forces the GUI to move in lockstep with the backend (something we're > trying to decouple I think) so that it's ready when new flags are > presented and knows what to do with them. Of course, 2 has the opposite > strengths and weaknesses. It decouples changes in the back end from > modifications to clients, but has the downside of putting some of the UI > decisions into that code. > > My preference would be for 3. It has the advantage of allowing the GUI > to present the user with a UI for a flag when it recognizes the flag, > and fall back to simply displaying a string when it doesn't recognize > the flag, which decouples the GUI from having to change whenever the > back-end changes. This disadvantage to this approach that I can see is > the added complexity in the initial coding for the client. > > If we go with option 1, severity probably isn't actually needed, since > the GUI has knowledge of what the flags mean. If options 2 or 3 are > chosen, I think severity is a necessity to help the clients with > organizing and prioritizing the material. > > Thoughts, comments? > > Brock > _______________________________________________ > pkg-discuss mailing list > [email protected] > http://mail.opensolaris.org/mailman/listinfo/pkg-discuss > _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
