signals

[David Zeuthen]

On Fri, 2003-09-19 at 22:40, Havoc Pennington wrote:
> So here are some desirable properties of the signal mechanism; I do not
> believe it's possible to get all of them at once.
> 
>  1. no round trips when starting up an app in order to request a signal
>  2. don't put signals with no listeners on the wire at all
>  3. have the bus only forward signals to clients that actually care
>  4. have signal connections associated with the well-known service 
>        instead of the client instance currently providing the service,
>        and also allow them to be associated with a single instance
>  5. have it work the same way with and without the message bus
> 

For the HAL project I'm working on, especially property no 3 is
desirable. Currently all changes in the device store is today broadcast
out to all clients, so for many clients they all get swapped in which is
bad.. This is not a problem right now (with the current state of the
project), but it's not scalable solution.

I guess one issue in 3 is how to tell the bus how to determine whether
you are interested or not, by some matching on the (typed) fields etc.
Maybe this is just an implementation detail?

Also (if it's not already available?), when emitting signals (which
would replace broadcasting if I understand correctly), it would be nice
to wait for replies from those clients who had registered interest. This
feature would make it very easy to implement the
do-the-stuff-before-shutdown (e.g. have fam stop watching files in a
file-system soon to be unmounted) of a device, as currently discussed on
xdg-list.

Today, I guess the only alternative is unicast and maintain a list of
which clients are interested.

Cheers,
David