PropertiesChanged signal, take 2

[David Zeuthen]

Hey Luiz,

On Thu, May 13, 2010 at 5:33 AM, Luiz Augusto von Dentz
<luiz.dentz at gmail.com> wrote:
> One can achieve atomicity by designing the properties correctly, since
> each property is supposed to be independent for each other,  and afaik
> we can have whatever we want as property since it is variant in the
> end.

Consider that you want to be able to add a new property without
breaking ABI. In order to do things "correctly" to achieve atomicity,
you might need to move properties around. And that's an ABI break.

(For example, consider you have two properties Direction and Speed.
Now, the semantics of the service is that these can only change
atomically. So in order to do things "correctly" I'm constrained (by
you) to put them in a pair. So I would have the DirectionAndSpeed
property instead. OK, now, in version 1.1 of the service (which I want
to be backwards compatible with 1.0), I want to convey the property
Color and the semantics is that this is supposed to be atomically
updated with Speed and Direction too. Except, I can't make this change
because it would change ABI. Also, I think it is unnatural to group
things together like that.)

> Also if the API depend on the order which the properties are
> changed I don't this PropertiesChanged can guarantee any.

Actually dictionaries guarantee order of elements so this works just
fine. Not that it matters much, the whole point of atomicity is that
things change... atomically... all at once!

Another reason why not including multiple properties is a bad idea
(e.g. why including only one is a bad idea), is the protocol overhead
per D-Bus message - it's not trivial - in fact, it's several tens of
bytes per message because of all the headers. If you have 100
properties this all adds up!

     David