Brock Pytlik wrote: > Here's a draft of the API that's been discussed previously. Please let > me know if there are capabilities not provided that the packamanger > needs that can't easily be handled by extending the progresstracker > class. The plan is to get the CLI working using the API and take the > feedback with the goal of having a fairly firm API in 3-4 weeks in the > gate that the GUI can integrate with. One thing that's still to come > from an API design perspective is to collect all the exceptions that > cross the API boundary together into a single module (or small number of > modules) so that they're accessible and easily tracked. > > To be clear, this is a draft. Names, functionality, and nearly anything > may change. Also, this version of the API is specifically for the most > dangerous operations, ones that can harm a users system: Install, > Uninstall, Image-Update, and Refresh. Others like list, search, info, > etc... will be added to this API in the future, but the first step is to > get the GUI and the CLI passing through the same interface on the > critical actions.
Hello Brock, I am very happy that you have made this proposal. Well done! I believe that this API will be changing in the next few months and will eventually become a little more stable, but having this will allow to track changes very quickly and for sure remove dosen of GUI's duplicated code. There is some missing functionallity, but we have agreed to go with critical things in the first cut to make sure we will never break user system. So we will need to make usage from some methods from image.py or fmri.py. What else I would like to see, not necessary in the first cut: Some functions which will allow to get information about packages itself. So we can't call any of the API functions if we don't know what are the packages, which means that some functionallity for getting list of packages toghether with informations about installed version/available versions (incorporated)/newest versions is needed. Adding/removing/changing authorities and mirrors. For the 2008.11 we will add license tab for packages. If this will be not provided by the API then we will need to pull the license calling other methods. > The flow of control for the consumer of a PkgClient object is: > 1) Create an API object. This establishes which Image the API object is > associated with and assigns a progresstracker (for simplicity) > 2) Call either plan_install, plan_uninstall, plan_image_update > 3) Call prepare > 4) Call execute_plan > > Cancel essentially sends you back one step (so if it's doing 3 and > cancel is sent, the state will return to 2). > Reset returns the state to just after step 1. Will api be back to the initial state after operations which actually finishes smoothly? I am not entirely convinced by coming back to n-1 step. What happens if for example someone will call plan_install(["SUNWone"], None) then will cancel during download operation and call plan_install(["SUNWtwo"), None)? best Michal _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
