launchpad-dev team mailing list archive

[Julian Edwards <julian.edwards@xxxxxxxxxxxxx>]

On Wednesday 12 May 2010 09:21:24 Bjorn Tillenius wrote:
> On Wed, May 12, 2010 at 08:55:51AM +0100, Julian Edwards wrote:
> > On Monday 10 May 2010 11:39:24 Leonard Richardson wrote:
> > > I take Francis's general point that we should think about the API that
> > > will feel most natural to the end-user, rather than publishing our
> > > internal API directly.
> > 
> > I find this quite hard to do since the API exposes our model objects.
> 
> So, does our interal model API feel natural to us, but not to our users? I
> doubt it. If our model API isn't good, we should take the opportunity to
> improve it. When Francis said that distribution and product attributes
> are implementation details, I'd interpret that as they are *storage*
> implementation details.
> 
> Even our internal API shouldn't expose those
> attributes as being writable. These should be written only inside the
> model object itself. If something outside the model object sets it, it
> should use the target attribute/method, which takes care of all the
> logic.

I guess what I am driving at, and I think you're in violent agreement, is that 
the internal model should be abstracted from the webservice users.  We can 
currently only do this in a half-hearted way with the things you mention 
above, but I also find this frustrating as I end up with massive and bloated 
model objects that contain both internal and webservice methods.

But the major issue is when we want to do quite large model changes (as we're 
doing with the build farm right now).  Backwards compatibility for webservice 
users is going to be somewhat challenging.

J