PropertiesChanged signal, take 2

Thiago Macieira thiago at
Wed May 12 15:50:24 PDT 2010

Em Quinta-feira 13. Maio 2010, às 00.22.32, David Zeuthen escreveu:
> Hey Lennart,
> Actually, thinking about it some more, it adds zero value having a
> PropertiesChanged() signal if it is not including the value!
> That is, it's not going to help any generic proxy mechanism. Either
> the client-side proxy is dumb and does a Get() on every access. And we
> won't need a PropertiesChanged() signal at all. And app-access (e.g.
> reading the property) is blocking because we need the Get(). Otherwise
> the client-side proxy is smart and does Subscribe() + GetAll() +
> updates cached value on receiving signals. And the app code can do
> non-blocking access. Hence, "true_no_value" actually makes no sense at
> all. So I think we should just remove true_no_value from the spec!

I don't agree. I think the use-case here is properties whose values need to be 
calculated or that are large.

You can cache the result, but you don't want to preemptively retrieve values 
unless you're going to use. The first time you call, the value is calculated 
and transferred, then cached. The next calls will be resolved locally, until 
such a time as the signal is emitted.

The signal simply indicates "discard your caches, the value has changed".

Thiago Macieira - thiago (AT) - thiago (AT)
  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: <>

More information about the dbus mailing list