launchpad-dev team mailing list archive

[Robert Collins <robertc@xxxxxxxxxxxxxxxxx>]

On Tue, Jun 7, 2011 at 1:54 AM, Aaron Bentley <aaron@xxxxxxxxxxxxx> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 11-06-03 09:57 PM, Robert Collins wrote:
>> So we should:
>>  - think twice before exposing attributes
>
> You make it sound like attributes deserve special consideration, but an
> attribute is equivalent to setter method and a getter method.  Their
> special syntax is really just syntactic sugar.  If we choose to change
> the underlying implementation later (so that they actually are a
> setter/getter pair), Python will support us.

Certainly, but there are limits to which one can fake out handling a
gone attribute.

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. We
could do various things like special casing where a project has no bug
teams ('bug supervisor is None', setting makes a new bug team), one
bug team (get returns the bug team, set replaces), but we will have to
either start returning some pretty strange data, or raise errors *in
released API versions* if someone tries to use the old API on a case
which we haven't managed to map backwards.

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.

Being able to unexport an attribute in only the most recent API
version would be useful in a few cases, but I think most cases where
we want to get rid of it, its because we -really have- gotten rid of
it and supporting it in any API version is either unreasonably hard or
impossible.

> So I don't think attributes deserve any more consideration than methods.
>
> We now expose attributes and methods in the "devel" API so that we we
> have license to change or remove them freely.  I don't think the
> circumstances that led to Brad's issue still apply.
>
> 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.

I'm very much in favour of letting web service clients do whatever
interesting thing they want to do. I don't want us to hamstring our
own future evolution on the way - something that we have done to
ourselves already.

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.

Further, our internal model and API model really should be different
(in that the internal model needs to know about caches of various
sorts, our upcoming microservices etc, and the web service API
shouldn't (by default)).

-Rob