launchpad-dev team mailing list archive

[Aaron Bentley <aaron@xxxxxxxxxxxxx>]

-----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-----