roadmap

[Luiz Augusto von Dentz]

> A kicker is that this one is probably a pain in the ass to implement
> in dbus-daemon. The bus would have to transactionally fail the match
> rule setup, waiting on a reply from the emitting client
> mid-transaction, or something like that. The bus must be sure the
> emitting client has switched on the signal before the bus can return a
> reply to the match rule requestor, because there's a race otherwise
> (when AddMatch returns we must guarantee that emissions will occur if
> state changes). This also makes AddMatch suddenly take
> nondeterministic time, i.e. the match-adder is now blocking on a
> random app to do something, instead of blocking only on the bus.

I guess you didn't understand me well, the daemon application can opt
to not implement AddMatch thus this is totally optional. So this must
not make any difference to bus daemon at all, meaning on bus daemon we
forwarding the call but don't wait for any reply from daemon
application. I don't want to change anything on the application side,
this way is totally transparent to the application and optional to the
daemon application.

>
> Anyway, I think this guy is not worth the trouble. But "register
> client" pattern could be.
>

They share the same idea but with different approaches.

-- 
Luiz Augusto von Dentz
Engenheiro de Computação