Discovering services

[Tako Schotanus]

Havoc Pennington wrote:
> Tako Schotanus wrote:
>>>> Exactly, when nobody is using them, but how can a service know when 
>>>> it's
>>>> not going to be used anymore? Maybe a generic interface, with 
>>>> ref/unref
>>>> methods that services could implement would be a solution.
>>>
>>> Some reasonable approaches are:
>>>  - time out and exit after being unused for a while
>>>  - require clients to register/unregister (and track if any
>>>    clients disconnect without unregistering, to avoid leaks)
>>>
>>> Distributed reference counting has lots of problems so we've tried 
>>> to avoid that. Eventually we might want some kind of generic 
>>> register/unregister mechanism, but it's not clear to me what that 
>>> would be like, so right now everyone is rolling their own suitable 
>>> for their needs.
>>>
>> Ok but this still won't work very well for those examples you gave 
>> before where a service might actually open a window or start a user 
>> visible application or something, won't it?
>>
>> Wouldn't that imply that activation should not be done automatically 
>> when only asking for introspection?
>
> I would not recommend activating stuff just to introspect it, no.

Ok, that would mean we're left with the static introspection info that 
could somehow be stored with the service.

But I agree with you that this might prove difficult as well because if 
people have to generate that info themselves they will either a) not do 
it, b) forget it, c) get it wrong (differences between the static info 
and the actual interfaces for example).

So one option might be to force activation of services to be 
light-weight, meaning that you are not allowed to do any "real work" 
until any method is called (eg. the print manager is not allowed to 
check for printers). But besides being a bit late in the game to start 
making changes like that it also won't work for those cases where the 
information is somehow dynamic because without the "real work" being 
done there just won't be any information (eg. what info is the print 
manager to return if it isn't allowed to check for printers?).

So I keep coming back to the question "why is it necessary to know/get 
the introspection information for a service that isn't running?".

Why can't we just say: "if you need to get the introspection information 
for an inactive service you must first activate it".

In the case of a DBus-browser tool we could just ask the user if he 
really wants to start the service before continuing. While for those 
cases where we just want to use our IDE to generate proxies we can 
temporarily activate the service to get the introspection info.

So again the question "what are the use cases for having static 
introspection info available on every DBus user's system?"

I think that in 99.9% of the cases the service needs to be activated 
anyway after having obtained the introspection information because we're 
actually going to use it, the rest of the cases seem to be restricted to 
programmers needing the info to interface with DBus.

-Tako