PropertiesChanged signal - races...

[David Zeuthen]

Hey,

On Tue, May 11, 2010 at 5:39 AM, Thiago Macieira <thiago at kde.org> wrote:
> Here's an idea:
>
> org.freedesktop.DBus.Properties:
>
> GetAndSubscribe(in string inteface_name, in string property_name, out variant
> value, out boolean subscribed)

(Would probably want a GetAll() to avoid message header overhead)

> That triggers fetching of a property for the first time and also subscribing
> for updates. The boolean return indicates whether the subscription is
> successful or not (some properties may not be watchable).
>
> The new property value would be carried by the PropertyChanged signal. But
> only watched properties would be ever notified.
>
> There would have to be a counterpart for unsubscribing. And the big issue is
> that bindings need to do the proper watching for services disappearing in
> order to decrease the ref-count of watched properties. It would be nice if the
> bus did that for us.

OK, but assuming with had this optimization that the bus would tell
when AddMatch() is called (for any signal), I think what are you
proposing isn't functionally different from just this

 - the proposed PropertiesChanged(a{sv} changed_props) signal

 - two new annotations
   - <annotation name="org.freedesktop.DBus.Properties.EmitsChanged"
value="true"/>
   - <annotation
name="org.freedesktop.DBus.Properties.EmitsChangedWithValue"
value="true"/>

It strikes me it's actually functionally equivalent, isn't it?

(Except that we won't get any optimization until we add the "tell me
when people subscribe to a signal" feature to the the message bus.)

Cheers,
David