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. _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
