PropertiesChanged signal

[David Zeuthen]

Hey Thiago,

On Fri, May 7, 2010 at 3:53 PM, Thiago Macieira <thiago at kde.org> wrote:
> Em Sexta-feira 7. Maio 2010, às 19.06.16, David Zeuthen escreveu:
>> Many people have asked for a generic mechanism to convey that one or
>> more properties has changed on an object so they don't have to roll
>> their own signals for this. Attached is a spec patch to define such a
>> mechanism. Some notes
>>
>>  - this new signal is optional
>>
>>  - even if implemented, a service may opt to avoid using it for huge
>> properties (e.g. probably want to avoid using it on a a 300 element
>> a{i{tt}ss} property called ChatRoomParticipants)
>
> I will not implement this property in QtDBus unless there's a subscribe method
> to trigger the emission of the signal. Anything else is wasteful.

While it is certainly your prerogative to not support this new signal
in QtDBus, please note this new signal is mostly a codification of
existing (and in my humble opinion good) practices. I mean, one way to
look at it is that if you have a remote object with properties you
want remote peers to know about these properties. So one way or the
other you will to transport these values over the transport and that
includes property changes too. Codifying this into a PropertiesChanged
signal is helpful because it allows bindings to automatically handle
this and it does so in a race-free manner and economical manner [0].

As to whether this signal is inherently wasteful, why is this any
different than any other (existing) signal? Sure, the way things
currently work you will _always_ have signal traffic flowing from each
name owner to the bus even if no clients are listening. While this
comes with some overhead [1] we can solve this by extending the D-Bus
protocol with something like this handwavy proposal:

 - during auth/handshake the bus daemon and the client negotiates
   the capability BUS_SIGNAL_NOTIFICATION

 - if successfully negotiated, the bus _guarantees_ that anytime someone
   subscribes to an signal of interest for the client, the bus will
send a message
   to let the client know. Ditto when that subscription's reference
count reaches
   zero.

(actually, related to this (and while it's still in my mental L1
cache) Colin suggested last week that the bus should include
credentials (pid, uid) for the sender when delivering a message. At
least the first time. This would allow for a traffic-less mapping from
unique bus name to pid, uid which is something system bus services can
benefit from as they use things like pid and uid when checking for
things like authorizations.)

Either way, my view is still that PropertiesChanged() is simply a
codification of existing (and in my personal opinion: good) practices.
The lack of certain optimizations should not stand in the way of
adding this to the specification

Thanks,
David

[0] : as opposed to e.g. current udisks/upower that just emits a
Changed() signal and then *each* client use GetAll() to read new
properties again - which is wasteful too.

[1] : whether the overhead is actually measurable is.. I think.. at
least debatable. I probably agree with you but let me be the devils
advocate: typically signal emission from a service is caused by some
external event (socket traffic, uevent, inotify event, whatever) so
the server is woken up anyway.. that leaves the bus daemon to get
woken up.. but since it's the hub chances are that its working set are
probably in memory and maybe even in a hot cache... I'm handwaving a
lot here and welcome any real measurement on devices of interest