On Wed, Apr 22, 2009 at 09:46:05AM -0700, Tom Mueller wrote: > Any class that is referenced via any parameters or return values from > the public API (the api module) is also part of the public API. The 3rd > parameter to the ImageInterface constructor is a ProgressTracker object. > So this exposes ProgressTracker as part of the public API.
According to you perhaps. However, nowhere was a specification for the ProgressTracker committed as part of the API. You can assert that it is part, but I don't think that should stop Shawn from making useful changes. If you've decided to add a dependency without getting a committment from the pkg team, that's not really our fault. > The Update Center updatetool implements its own ProgressTracker as part > of using this interface and that progress tracker has dependences on > other parts of updatetool and the toolkits it uses (wxWidgets). I'm > assuming that you are not really suggesting that we put all of > updatetool into the gate. No. I'm suggesting you modularize your progress tracker or live with some change. This project is still in its development stage. You don't get to demand that we hold up development work. > I would suggest modifying the new methods within the ProgressTracker > class so that they just return rather than raising a > NotImplementedError. If someone is interested in doing something for > those methods, they can be overridden in the subclass. If not > interested, the subclass doesn't need to do anything. I'll leave this up to Shawn. If he thinks that it's an appropriate change, then that's fine with me. -j > [email protected] wrote: >> Tom, >> >> On Wed, Apr 22, 2009 at 11:00:36AM -0500, Shawn Walker wrote: >> >>> Tom Mueller wrote: >>> >>>> Shawn, >>>> >>>> Isn't the addition of the ProgressTracker methods that raise a >>>> NotImplementedError an incompatible change to the API? A program >>>> that extended ProgressTracker previously and worked without having >>>> an exception raised will now have an exception raised when these >>>> methods are called unless they do what you had to do in >>>> installupdate.py (implement empty methods). >>>> >>> These are methods that subclasses need to implement, I'm not sure >>> what else I can do here. >>> >>> As far as I know, we've never made the decision how the >>> progresstracker class ties to the public client API and how the API >>> might be rev'd. >>> >>> Also, as far as I know, the programs in the pkg(5) gate are the only >>> ones to implement progress trackers. As such, that particular aspect >>> of this change really isn't a concern for me. >>> >> >> I agree with Shawn on this one. The ProgressTracker is a separate >> interface from the versioned API that's exposed to client callers. >> Anyone who has extended a version of the ProgressTracker and left their >> code outside of the gate is essentially using a consolidation private >> interface. If you have a custom progress tracker that you'd like to >> avoid being broken by incompatible changes, I'd encourage you to >> integrate it into the pkg gate. >> >> -j >> > > begin:vcard > fn:Tom Mueller > n:Mueller;Tom > org:Sun Microsystems, Inc.;SWI Install/Update Software > adr:;;21915 Hillandale Dr;Elkhorn;NE;68022;USA > email;internet:[email protected] > title:Senior Staff Engineer > tel;work:877-250-4011 > tel;fax:877-250-4011 > tel;home:402-916-9943 > x-mozilla-html:TRUE > version:2.1 > end:vcard > > _______________________________________________ > 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
