launchpad-dev team mailing list archive

[Robert Collins <robert.collins@xxxxxxxxxxxxx>]

On Tue, Jun 7, 2011 at 8:41 AM, Aaron Bentley <aaron@xxxxxxxxxxxxx> 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