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
