PropertiesChanged signal

[David Zeuthen]

Hey Will,

On Sun, May 9, 2010 at 4:58 AM, Will Thompson
<will.thompson at collabora.co.uk> wrote:
> On 07/05/10 18:46, Lennart Poettering wrote:
>>
>> Hmm, could we extend the spec a little and say that a PropertiesChanged
>> signal with an empty dict means "some property changed"? I know quite a
>> few projects which have something like this (and for a reason, since the
>> property data is big and more often not read than it is read), including
>> some of my own.
>
> So what should the proxy objects do in this case? I guess the idea is just
> to invalidate the local property cache so that if someone asks the proxy for
> some properties, it goes away and re-fetches them.

Well, the whole point about PropertiesChanged is in fact to avoid
having proxies do stuff like that. I mean, omitting the property value
in PropertiesChanged() only so the client needs to retrieve it via
Get() is going to generate more traffic... of course, if you only
occasionally expects a client to do this it might be worth it...

(Also, getting the property value via Get() introduces a new race -
the value might have changed between receiving the signal and the time
the Get() hits the server...)

> It strikes me that it
> might be nicer to be able to say that a particular property changed to an
> unknown value, but I can't see a way to wedge that into an a{sv}. :)

It could be a{smv} if we had maybe types - or the signature of the
PropertiesChanged signal could be

 PropertiesChanged ( s interface_name,
        a{sv} changed_props_with_values,
        as changed_props_without_values);

I mean, we can make it as complicated as we want to.... But I don't
think we should... Because from a 50,000 feet point of view, I'd like
to think that if you have a D-Bus interface where you elect to not use
PropertiesChanged for a property, chances are high that you can
require custom code at the client side for handling properties anyway.
For example, for the canonical example I gave in the beginning you'd
simply have

 ChatroomParticipantsChanged (a{iss} added_participants,
        ai ids_of_removed_participants);

e.g. a signal with the actual delta.

Again, from a more philosophical point of view, I still like us to
encourage developers to use PropertiesChanged because it makes writing
client-side code much simpler (since library code such as GDBusProxy
can be used without the application programmer having to worry about
race conditions etc.). For the < 5% of cases where it is not desirable
to use PropertiesChanged(), I'd rather such services be extremely
explicit about it (by using a mechanism not related to
PropertiesChanged() at all). IOW, I don't think it's desirable to
"pollute" the PropertiesChanged() signal with something that is a < 5%
case.

(Sorry for the potentially rambly message!)

Cheers,
David