launchpad-dev team mailing list archive

[Martin Pool <mbp@xxxxxxxxxxxxx>]

On 18 May 2011 21:03, Robert Collins <robertc@xxxxxxxxxxxxxxxxx> wrote:

> Sure. I think we may have /some/ apis we choose to expose externally, but the default is internal. And this isn't a question of openness: the control protocol for the blob-store for Launchpad is only relevant to LP servers & scripts.  [....]  I don't think we should commit to productising by default. We may want to productise as much as 50% of our services, so its a good question.

+1

> But those that we don't won't fit in the 'launchpad
> API' stack because lazr.restful exposes /one/ service - and we're
> going to have N separate services. We /might/ use lazr.restful for
> them, but its not a no-brainer, and it is a separate question.

By "external api" I meant "external machine interfaces to launchpad",
not "stuff published through lazr.restful and used by launchpadlib."
Evolving towards multiple related services, and considering using
something other than lazr.restful for them internally and then perhaps
externally sounds great.

>>  * I'm not sure quite what "make creating and destroying services as
>> lightweight as possible" means but it certainly sounds like I want it
>> for external clients too ;-)
>
> I don't think you do. For external clients you want stable API's.
> Internally we want to evolve rapidly.

OK, I see, I thought you were talking about starting new service or
clients instances quickly (for which eg wadl is a problem).

I feel there is something in bzr's experience with api versioning that
might relate to Launchpad, and the current approach is not quite
right.  (The problems are not identical, since for instance there's
probably little demand for running new clients against old Launchpad
code.)  There are factors that push clients towards just writing
against devel, at which point aiui they don't get any stability
promises.  But this is pretty much orthogonal to internal structure,
and probably a matter for a different thread.  The point still remains
that internal code can be expected to be much more in sync than
external, on a scale of perhaps weeks vs years.

Martin