PropertiesChanged signal, take 2

[Thiago Macieira]

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
> 
>       org.freedesktop.DBus.Properties.ChangedSignal
>       org.freedesktop.DBus.Properties.ChangedSignalWithFalse
> 
>    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 
it.

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 
states.

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 
implementations".

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 
annotation?

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
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.freedesktop.org/archives/dbus/attachments/20100511/141012af/attachment.pgp>