Discovering services

[Tako Schotanus]

Carlos Garcia Campos wrote:
> El mar, 04-07-2006 a las 18:29 +0200, Tako Schotanus escribió:
>   
>> Havoc Pennington wrote:
>>     
>>> 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.
>>>       
>> But what would be the use  of asking for introspection information on a 
>> service that is not running yet? In a lot of cases there won't be any 
>> information yet (like for example the service that manages all installed 
>> printers) or it might in some other way be dynamically generated/determined.
>>
>> So what is the usecase where you would want to know what a non-activated 
>> service supports?
>>     
>
> It's useful to know, at least, which services are available even if they
> are not activated. For example, when I was working on porting
> libpanel-applet to dbus each applet had a .service file, so I needed to
> know which .service files were available in the system to build the "add
> to panel" menu. IMHO it's a reasonable usecase. 
>
>   
Sure! I'm not denying the usability of this feature, but knowing the 
possible use cases might give us a hint how best to tackle it. For 
example, you talk about the service files only, which would suggest you 
weren't really interested in the objects served and the interfaces 
implemented by them. But for sure there will be other cases where that 
information is really useful.

But on the other hand there are situations where static introspection 
info just won't work so it won't solve all the problems and just 
automatically activating a service when someone asks for the 
introspection info seems like a bad idea in general.

-Tako