PropertiesChanged signal, take 2
thiago at kde.org
Thu May 13 02:07:43 PDT 2010
Em Quinta-feira 13. Maio 2010, às 01.03.43, David Zeuthen escreveu:
> On Wed, May 12, 2010 at 6:50 PM, Thiago Macieira <thiago at kde.org> wrote:
> > 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".
> The value of.. what has changed? I mean, that's the question!
> The idea is that you can use the PropertiesChanged() signal to update
> property caches so each client (and you may have many), each won't
> need to do GetAll() every time this signal is received. Thus, you can
> get by with 1/Nth of the traffic needed. And avoid race conditions.
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
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
Size: 190 bytes
Desc: This is a digitally signed message part.
More information about the dbus