PropertiesChanged signal, take 2

[David Zeuthen]

Hey,

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.

     David