PropertiesChanged signal, take 2

[David Zeuthen]

On Thu, May 13, 2010 at 5:07 AM, Thiago Macieira <thiago at kde.org> wrote:
> I don't agree.
>
> Imagine that the property updates, but no client is going to use that property
> now. Then it updates again, and again. (that's 3 updates)
>
> Now, the only client needs it. That was one third of the traffic than
> broadcasting the solution required, assuming the property payload is
> significant.

Presumably a property on an object exists because the designer of the
object thought the property was useful.... and, of course, it's
subjective whether a given property matters to a given client. For
example, the gnome storage automounter daemon doesn't care about the
DriveAtaSmart property (that contains health information) wheares the
gnome-disk-failure daemon does (so it can show an user that the disk
is failing). OTOH, the latter don't care about the VolumeIsMounted
property but the former does. And so on. So udisks service (the owner
of these objects with these properties) cannot really afford the
luxury of assuming what's important to its clients. So it emits
PropertiesChanged for all.

Where am I going with all this? I'm trying to explain that when you
cache a value, then, well, sometimes you do so in vain. Because
sometimes the memory and bandwidth is wasted because, well, no-one was
going to use whatever you had in your cache. That's simply just the
nature of caching and it's not specific to D-Bus at all, it also
relies to L2 caches, web searches, whatever...

Another observation is that this "reduction in bandwidth" argument
only applies to the spoke from the server to the bus - the bus itself
will still need to send out N copies to each client.

Anyway, the "reduction in bandwidth" thing was really just an aside.
The main thing I wanted to say was just that true_no_value really
doesn't help at all because PropertiesChanged() don't convey such
properties at all.

     David