On Tue, Jun 7, 2011 at 8:41 AM, Aaron Bentley <aa...@canonical.com> wrote: > -----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.
Oh, I agree, getter/setter pairs are no better than properties (and properties are much nicer, at least much of the time). Uhm, I guess to me methods and properties are both attributes and I was being perhaps overly general. >> 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 agree with you. >> 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. I think the cheapest thing we can do is not expose things; after that we can put it in devel, and most expensively we can promote it beyond devel. The cheapest thing is also the least useful, being in devel is fairly useful (but folk still may depend on it even though we advertise no stability) and being in a long-term API version has the greatest availability for use. The balancing act I refer to is deciding whether to expose something *at all* and if it needs to be guaranteed for a long time; inputs to that decision are things like our confidence in the model (for instance, have we finished iterating on our design), whether we /want/ non-datacentre clients reading/mutating the particular thing, stakeholder requests, specific projects... >> 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? I think thats a real possibility. For instance, the 'file a bug' story for apport and now the 'desktop login' stories are ones where there are CD's shipped, which Ubuntu will support for 7 years, which we want to keep working. Now, we probably can coordinate changes to e.g. lucid's bug filing story with the Ubuntu team, but things like blueprints, questions, branches are not covered by those constraints. We should be able to evolve those parts of the system as cheaply as possible: one of the major stakeholder themes is for us to be faster at evolving Launchpad. -Rob _______________________________________________ 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
