Discovering services

Aristid Breitkreuz aribrei at arcor.de
Thu Jul 6 13:57:53 PDT 2006


Hi,

I've been thinking about similar problems like those described below
and ... well ... want to share my ideas.

Am Dienstag, den 04.07.2006, 02:10 -0400 schrieb Havoc Pennington:
> Carlos Garcia Campos wrote:
> > 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.

In general a service should err must self-deactivate when nobody is
using it. As an OPTIMIZATION services can be kept open for reuse until
some timeout expires. (This was quite an important thought I had while
designing some component for some framework. But it was NOT about D-BUS
services.)

> 
> 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.

When a service is activated by D-BUS, there should be no side effects
like windows opening EVER. Windows might be opened after say a call of a
method or when a service-providing program is started by the user but
not, no, never, if a service is activated by D-BUS.

If activating a service is slow... well do it asynchronously. There is
more than one service to Introspect usually and there is no good
alternative to starting the service IMO. At least once, caching is of
course an option.

> 
> 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.

It would be possible to optionally cache introspection information but
only if the service feels able to do so. This would have the advantage
of dynamic interfaces still being possible and being implementable quite
transparently. The disadvantage being that the service has to be started
at least once but I think that is acceptable if we agree that we don't
have to expect windows opening.

> 
> Havoc
> 

Aristid

PS: I'm no D-BUS expert but I think my views are nevertheless valid.
Please forgive and correct any misconceptions I might have. I'm not
afraid of constructive discussion.



More information about the dbus mailing list