Discovering services

Havoc Pennington hp at redhat.com
Mon Jul 3 23:10:32 PDT 2006


Carlos Garcia Campos wrote:
> 
> Maybe it's better to add a new method instead of using ListNames. 
>

Yeah, I think it would be better to add a method that specifically lists 
"activatable services" or something and only includes stuff from 
.service files (does NOT include the live/running names).

> The patch is available here (against cvs head, I haven't been able to
> get dbus from anongit): 
> 
> http://carlosgc.linups.org/files/dbus-list-services.diff

It looks pretty good, I would suggest two things:
  - separate method from ListNames
  - add test coverage - since ListNames itself isn't tested yet this
    may be a little work, but it should not be too hard - if you look
    at the tests that do an activation, you just need to ListNames after
    the activation and be sure the activated name is listed, and call
    your new method before the activation to be sure it's listed as
    something activatable. You want to hook in to
    bus/dispatch.c tests probably which will let you test the OOM
    handling.

> Another problem we have found with "atomato" is that we need to call
> introspect method for every service, but we don't want that a service
> which was not active, keep active after returning introspect info. 
> 
> Is it possible to deactivate services or something like that?

This is a pretty major can of worms. In general services should 
"self-deactivate" I would say - e.g. after a timeout, or when nobody is 
using them.

But, activating everything possible seems pretty scary to begin with - 
you might be launching apps left and right in essence. Could be 
slooooooow and have bizarre user-visible effects such as windows opening.

If you need this, I think we'd have to look instead at some way to 
install the introspect information in files. But, that's a pretty large 
project and adds a fair bit of complexity.

Havoc



More information about the dbus mailing list