launchpad-dev team mailing list archive

[Ian Booth <ian.booth@xxxxxxxxxxxxx>]

Hi James

> 
> Firstly I wanted to note that lp.projects is a heterogenous collection
> isn't it? You can access both projects and project groups with it, and
> don't they have a different interface?
>

AFAIK, project groups are handled separately, using lp.project_groups


> Secondly I'm wondering why this is trying to be a collection at all. You
> wouldn't even want to iterate them, and if they are heterogenous then
> putting them in a collection seems odd. Would it be better for them to
> be accessed as top level objects (lp.myservice)?
>

You and Francis both asked whether exposing the services as a collection
is the right thing to do. The reason I like that approach is that it
provides a level of discoverability and keeps the launchpadlib interface
manageable for want of a better term. If we access each individual
service as a separate top level object, we have
lp.service1
lp.service2
lp.service3
... etc

Compare the above with

lp.services['service1']
lp.services['service2']
... etc

So when we add a new service, the launchpadlib interface doesn't change
(acquire a new top level object), and I view this stability as a good
thing. Plus, it is possible to iterate over the named services and see
what's there, what service interfaces are implemented, what methods are
available etc. ie a classic discoverability pattern.

Even though the services are heterogeneous, they all extend IService
which provides common behaviour such as service lifecycle management
hooks etc - well not at the moment, but the idea is there. So it can be
argued that one would need to be able to iterate over all services in
the collection and start/stop them etc, or ask for stats or whatever.

So that's my take on the question of putting the services in a collection.