PropertiesChanged signal, take 2

[Thiago Macieira]

Em Quinta-feira 13. Maio 2010, às 12.59.21, David Zeuthen escreveu:
> 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.

That's not about whether the property is important for clients.

It's about whether calculating the property's value and broadcasting it is 
expensive. An expensive property may be important to a client (say, getting 
ATA health info from hardware), but then the client will simply proceed to 
request it anyway.

Between that extra expense of requesting the property, and the opposite effect 
of always broadcasting them, even if no one is consuming, I'll take the former 
case.

Of course, this is solved by subscribing to property changes.

> 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...

I'm not against caching. I'm against calculating things in vain.

> 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.

You started the bandwidth argument :-)

> 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.

Why not? I don't get your statement here. To me it sounds like we can support 
Lennart's request without any trouble.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Senior Product Manager - Nokia, Qt Development Frameworks
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.freedesktop.org/archives/dbus/attachments/20100513/57b32078/attachment-0001.pgp>