Re: dbus activation on signal

On Thu, Mar 19, 2015 at 12:01 PM, Simon McVittie
<[email protected]> wrote:
> On 19/03/15 10:27, WaLyong Cho wrote:
>> As I knew, dbus auto activation is only working for method call and
>> signal what has destination. But generally, in case of signal, the
>> signal destination is not of listener(what hope to be activated).
>
> Correct. D-Bus does not have a facility for services to be activated
> automatically as a result of a broadcast signal.
>
> If it did, there are some nasty ordering constraints - I certainly
> wouldn't want to have to delay delivery of a broadcast until all
> interested services had started up! - so I don't think adding this
> feature would be a good idea.
>
>> If dbus has no solution for this and it is not acceptable functionality,
>> make a new daemon. The new daemon will listen all of signals and a
>> special signal was sent then activate a set of other processes.
>> But when the activated process can not receive the signal. Because that
>> already sent in the past.
>
> This approach is certainly one possibility.
>
> If your D-Bus API is such that the activated process can perform state
> recovery, then there's no problem. For instance, suppose you want to
> start an activated service whenever the networking service
> (NetworkManager or ConnMan or similar) detects a wireless network, which
> does something on all the wireless networks.
>
> On startup, the activated service should connect to the
> NewWirelessNetwork signal (or whatever your networking service calls
> it), but ignore it if received; then call GetAllWirelessNetworks to see
> what is currently available; then on receiving the reply to
> GetAllWirelessNetworks, behave as if all those networks had just been
> detected, and stop ignoring NewWirelessNetwork.
>
> If you don't or can't do state-recovery, then in general your system is
> broken *anyway*, because you might miss a wireless network that appears
> after you have started up, but before you have connected to the
> NewWirelessNetwork signal.
>
> The same applies to any other (signal, state-recovery method) pair.
>
>     S

I think kdbus can solve the dependency issues. As well as signal
activation, we had the need of being able to activate daemons that are
implementing certain interface.

Umut

>
> --
> Simon McVittie
> Collabora Ltd. <http://www.collabora.com/>
>
> _______________________________________________
> dbus mailing list
> [email protected]
> http://lists.freedesktop.org/mailman/listinfo/dbus
_______________________________________________
dbus mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/dbus