PropertiesChanged signal, take 2
thiago at kde.org
Tue May 11 14:21:19 PDT 2010
Em Terça-feira 11. Maio 2010, às 20.07.27, David Zeuthen escreveu:
> Hey again,
> Here's take two of the PropertiesChanged spec patch reworked after
> review here on the list (thanks guys!). Notes:
> - The PropertiesChanged() signal is optional. An application can convey
> support for this signal by either including or excluding it from the
> returned introspection data (much like apps not supporting (or predating)
> the GetAll() method does not include GetAll() in the introspection data.)
> - An object can use PropertiesChanged() but opt out of using it for one
> or more properties by setting either of
> to false.
> The intent of the patch is simply to standardize existing behavior,
> not completely replace or rework the org.freedesktop.DBus.Properties
> interface or add or depend on various optimizations that are not
> specific to this patch.
Ok, so from what I understand from your proposed changes, we'd add two
properties to org.freedesktop.DBus.Properties, which control whether the
signal is emitted and, if it's emitted, whether the value is emitted alongside
That would mean the setting is per object, which means we have a good deal of
control of whether signals are emitted unnecessarily or not.
You're also saying that an object that has properties changing far too
frequently should set its flag to off. Would this property be read-only or not?
If it's read-write, then remote apps should set the flag to true to enable the
emission of the signal.
Do I understand it correctly?
Problems I see in the proposal:
1) the property names aren't very descriptive. I recommend
"PropertyChangedSignalEnabled" or "EmitsPropertyChangedSignal".
2) I think the two properties should be one property with three different
3) if the value isn't emitted, what is the value in the dictionary supposed to
be? We should describe as "the value is arbitrary and should be ignored by
4) how does the client know whether the value in the dictionary is meaningful
or not? It needs to query and keep up-to-date with the setting of whether
values are included in the signal or not. I recommend that information being
broadcast in the signal itself to avoid the extra round-trip needed.
5) in order to observe properties, clients must ensure the signal is configured
to being emitted. In practice, it means the clients will just make the call to
enable anyway.. Seems like a bit of a waste for me.
6) should any client ever set the setting to false? Any one client doesn't
know whether there are other clients watching for the signal. Conclusion: once
enabled, the signals will be emitted forever. I don't like this.
7) shouldn't the defaults be defined per interface, or even per property? That
is, whether the property:
- can emit signal at all
- emits the signal by default
- the value of the property is included in the broadcast
isn't a decision to be made on a per-property (or per-interface) basis? If
that's the case, shouldn't we instead add a property- or interface-wide
Also note that interfaces that have at least one property that is "can emit
the signal" (whether it does so by default or not) will require updated
versions of the many bindings. Well, not a problem with the proposal, but I
thought this should be pointed out.
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