Discovering services

[Tako Schotanus]

Havoc Pennington wrote:
> Carlos Garcia Campos wrote:
>>
>> where should I add the test stuff? bus/test.c? I still don't know how
>> the tests work. 
>
> I think bus/dispatch.c has most of the tests for the bus, in 
> particular those that test OOM handling. You should be able to roughly 
> just copy one of the other tests in there. It's a little bit tricky 
> since it's all in one process, you have to avoid blocking when the 
> other process hasn't sent something yet, or it hangs. Just do 
> DBUS_VERBOSE=1 and look at what happens if your test doesn't work.
>
>>>> 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.
>>
>> 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?

-Tako