PropertiesChanged signal

[Marcel Holtmann]

Hi Mickey,

> > > And while we're there we could/should also fix the client-based signal
> > > matching, which is IMO one of the major design flaws in DBus.
> > > I know that the desktop people don't care, but still...
> > 
> > What is the issue?
> 
> Two issues:
> 
> 1.) Listeners are always woken up on any kind of signals (to run the
> match function), no matter whether they are listening to a certain
> signal or not. That's a waste of CPU hence battery.
> 
> 2.) Signals are being computed and sent no matter whether anyone is
> listening or not. Again a terrible waste of CPU.
> 
> Both issues are commonly worked around by introducing additional
> application-specific protocols, such as the 'agent-based' approach we
> see in bluez, connman, etc.; still it's merely done due to the lack of
> server-side signal handling.

I have to comment here. The agent concept used in BlueZ etc. has also
other reasons than just signal filtering. Actually signal filtering is
just a nice byproduct.

It has more to do with the bus name. All agents are only using unique
bus names and that way we can have multiple of them and the main daemon
can easily monitor if they are present or have died unexpectedly. You
also don't need to punch holes in the security policy for these agents
based on there potential bus names.

The 1:1 communication with method calls is also important since that way
we can just return the result of the request.

Regards

Marcel