I'm not suggesting that you should stop working. My point is that you'll have less work to re-do if you add API functions as you go along. Adding a wrapper for set_authority probably wouldn't take a lot of effort; however, it would save you the trouble from having to fix that code again, when something in the underlying implementation is modified. Given that we're all busy, it seems like such an approach might be desireable, instead of scheduling time to re-write code that we know will get broken.
*shrug* -j On Fri, Feb 06, 2009 at 11:30:29PM +0000, John Rice wrote: > J - we do hear you loud and clear. The API bugs are filed, but we need > to keep working whilst they are being implemented. We are aware that as > soon as they are available we will need to change the code to use the > API's, we've built this additional integration work into the schedule. > It would be great if the API's were all available for us to use right > now, but that is not the case and given the work loads the ips team is > under, people are moving as fast they can. So its not ideal but using a > limited number of private API's does let us make forward progress. Its > only by getting the GUI features out there that we get feedback on what > works what doesn't, what issues of scale and so on need to be addressed. > > Hopefully within the next month the various API's we need will come on > stream and we can remove all reference to the private API's. At the same > time the CLI can be changed to use these new API's so both clients are > in sync and protected from underlying implementation changes in the ips > core. > > JR > > [email protected] wrote: > > Once again, I'd like to repeat my warning about not using the client > > API. The authority enable/disable code is reaching into the image > > object directly. Despite lengthy discussions explaining why this is a > > bad idea, these warnings have fallen on deaf ears. It's entirely likely > > that the authority implementation, and it's location in the image > > object, will change in a future putback. This means that your authority > > support will end up being broken. If you have an API method that is > > shared between the CLI and GUI, we can make sure these problems don't > > occur. > > > > If a method doesn't exist for an operation that you're trying to > > perform, file a bug against api-python or consider adding the support > > to the API. > > > > -j > > > > On Thu, Feb 05, 2009 at 12:38:25PM +0000, Michal Pryc wrote: > > > >> Padraig, > >> LGTM, with one minor cosmetic thing: > >> > >> http://cr.opensolaris.org/~padraig/ips-6014-v2/src/gui/modules/repository.py.wdiff.html > >> > >> Line: 354 (is this empty line needed?) > >> > >> Michal > >> > >> Padraig O'Briain wrote: > >> > >>> The webrev http://cr.opensolaris.org/~padraig/ips-6014-v1/ fixes > >>> 6014 Would like ability to disable authorities rather than deleting them > >>> 5202 Catalog is refreshed too often for Manage Repositories dialog > >>> operations > >>> > >>> A check box is added to the repository list to allow enabling and > >>> disabling of a repository. > >>> All the rows have been made sortable but the data is initially presented > >>> unsorted. > >>> For 5202 we avoid refreshing the catalog if the only changes the user > >>> made was to change the preferred authority and change it back to the > >>> original preferred authority before closing. > >>> > >>> Padraig > >>> _______________________________________________ > >>> 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 > >> > > _______________________________________________ > > 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 _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
