PropertiesChanged signal

[Lennart Poettering]

On Fri, 07.05.10 22:28, David Zeuthen (zeuthen at gmail.com) wrote:

> Either way, my view is still that PropertiesChanged() is simply a
> codification of existing (and in my personal opinion: good) practices.
> The lack of certain optimizations should not stand in the way of
> adding this to the specification

I agree with this sentiment.

Moreover I would say that enabling/disabling these signals for
optimization is orthogonal to the interface itself.

I.e. I would argue that if you require some Subscribe() method to be
called before these signals are generated, then that is fine and up to
you, but not necessarily has to be already covered by David's spec
extension.

For example, in systemd I do have Subscribe() call that clients have to
call before I send out any kind of signal. As long as no client is
connected that called that function I will not bother at all with
sending out signals.

In the long run it might make sense to codify Subscribe() or something
similar in a spec too, but I see no immediate reason for that right now.

Maybe David's spec change should mention that sending out signals might
require enabling via some explicit method call first, but otherwise I
think the spec is fine the way it is.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4