-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11-06-06 04:14 PM, Robert Collins wrote: > Certainly, but there are limits to which one can fake out handling a > gone attribute.
I agree. But I'm arguing that those limits also apply if you've exposed getter/setter pairs instead, so it seems strange to single out exported attributes. "think twice before exposing attributes" could encourage people to write getter/setter pairs instead of exposing attributes, and I think that would be a perverse outcome. > Imagine for a second that we remove the bug supervisor attribute from > project (and replace it with something (call it bug teams) that > represents a single communities interest in a project; commercial > projects get to review who has such an interest, open source projects > allow any community that wants to step up and play to do so). > > Irrespective of API versioning, we'd have a -real- hard time handling > either get or set requests for the old bug supervisor attribute. And my point is that the problem is the same whether get or set requests are exposed as Product.bug_supervisor or Product.getBugSupervisor() & Product.setBugSupervisor(). > I'm arguing that if we've decided to change the model, then we *really > have* changed the model and should accept that that is an incompatible > change across /all/ our API versions. I have no disagreement with this. >> If you mean "expose attributes" in the broad sense that we expose them >> as part of the user model, regardless of how they are manipulated, I can >> see some logic in that. But there is a constant push to expose more and >> more, so that our web service clients are just as empowered as local >> code is. At times, you yourself have championed that. > > I think there is a balancing act with our API's and when and how much we > expose. Could you explain why you think that? ISTM that we need to think twice when we promote something to an API version other than "devel", but not before that. > Much of this is fallout from the design of the current web service > model: because we present a very large facade as a single 'version' of > the service, and its all described as a single service, when we > promise 7 years support, we're promising for -everything- for 7 years, > but not all our API's or our model are needed by the desktop clients > for whom we were making that promise. Do you imagine that if we provided Launchpad as a federation of APIs, some of them would have a 7-year guarantee and some would not? Aaron -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk3tO18ACgkQ0F+nu1YWqI2vpgCfbextu+ZPxZo0m+TYa+MvdwIz r7oAnReoIYd1t3uY1+8+Zb28py8RMZSE =P9UW -----END PGP SIGNATURE----- _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
