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