PropertiesChanged signal - races...

[David Zeuthen]

Hey,

On Tue, May 11, 2010 at 8:37 AM, Thiago Macieira <thiago at kde.org> wrote:
>> It strikes me it's actually functionally equivalent, isn't it?
>
> Almost. The difference is that you're storing this information in the
> introspection, which I think is the wrong place to do so:
>
> 1) when the introspection is used to generate client/server code, the
> annotations are irrelevant -- the ability to emit or emit with value are
> dependent on the binding of the server, not on the author of the interface

I disagree. Whether a property ChatroomParticipants emits
PropertiesChanged (with or without value) is very much a decision of
the author of the interface. It's as much part of the programming
contract as whether the interface emits _other_ signals (or not). It
really is part of the ABI. E.g. it's not something that is left up to
some implementation or binding or whatever.

One way to think about it is that PropertiesChanged is a simple way of
reducing the amount of custom signals you need to add / implement.
E.g. instead of

 interface com.acme.Foo1 {
   property i speed;
   property s mood;
   signal SpeedChanged (i new_speed);
   signal MoodChanged (s new_mood);
 };

 interface com.acme.Foo2 {
   property i speed;
   property s mood;
 };

where version 2 of the Foo interface simply relies on
PropertiesChanged() to convey changes to the :speed and :mood
properties.

In fact, only conveying this information at runtime (and not knowing
it at compile time) actually makes things a lot more difficult. This
is simply because the programmer isn't really guaranteed whether
PropertiesChanged include, say, the ChatroomParticipants property
until run-time. So he has to add two paths for this if he wants to
handle both cases, e.g. case 1. the ChatroomParticipants value is
included in PropertiesChanged; and 2. it isn't.

> 2) for that reason, you cannot rely on a property emitting notification unless
> you communicate with the remote interface. I'd rather get that information in
> a D-Bus proper structure, rather than parsing XML.

No-one likes parsing XML but it's what we have right now. I mean, I
really don't think it's a good idea to add yet another way to describe
an interface. That way we'll end up with two ways to describe an
interface: 1. Introspection XML; _and_ 2. whether properties change or
not. And both pieces of information are crucial in order to write code
to interact with the interface in a meaningful way....

FWIW, several people have suggested a way to introspect an object that
gives back a binary version of the introspection data. I think that
could be interesting but as with any optimization, I'd like to see
some hard numbers that XML parsing is a hot spot.... I mean, all
(most?) bindings for C-like languages don't even parse XML at run-time
anyway!

And, again... adding binary introspection XML... I mean, that's just
yet another optimization (in addition to the one where the bus daemon
notifies signal emitters whether they should bother) that is outside
the scope of the very simple thing I'm proposing here: standardizing
existing behavior by introducing a PropertiesChanged() signal....

     David