PropertiesChanged signal, take 2

[Lennart Poettering]

On Wed, 12.05.10 16:09, David Zeuthen (zeuthen at gmail.com) wrote:

Heya,

> On Wed, May 12, 2010 at 3:49 PM, Lennart Poettering <mzqohf at 0pointer.de> wrote:
> > Hmm, Could we extend this a little so that we can set the annotation on
> > the class interface itself too, to set a default for the interface that
> > is then overridable per-property? In systemd I have a metric truckload
> > of properties on each service, which means that the introspection data
> > is already kinda big, and instead of annotating every single property as
> > EmitsChangedSignal=true_no_value I'd prefer having to annotate that only
> > once for the interface. Makes the introspection XML blurb smaller and
> > more readable.
> 
> Now I'm curious: why do you want to use true_no_value for _all of
> these_ properties? Are each of them really that big? (If so, some
> design input from me, if you wanted to know, would be to reconsider if
> they really should be properties at all).

Well, most of my properties seldom change, but when they do, they tend
to change all at once. Most of the props are irrelevant for 99% of the
clients, some of the props are a not really small, some non-trivially
generated at time of querying. Putting that together you have quite a
number of properties with partly bigger size and you hence might want to
avoid sending them out gratuitously because nobody cares about their
data, but still inform the clients that they changed, for the 1% of
clients that care, so that they can query them then.

So, in the end "true_no_value" seems more appropriate for me in my case
for most props, with maybe a small subset of them (such as state enums)
set to "true", because every client will care about them.

And, yes, these properties should be properties.

> Please remember that the point of the PropertiesChanged() signal _in
> the first place_ is to make it easy to write D-Bus clients. Meaning
> that you don't need to do all kinds of things like connecting to
> signals or do async or blocking calls to read a property. You simply
> connect the signal, call GetAll() and then you are done (updating the
> local cached value as you go). Which can only be achieved if the
> service actually uses the PropertiesChanged() signal as designed.

Currently what I need I have implemented with my home-grown Changed()
signal, that carries no parameters. I works quite fine, but of course it
would be nicer to follow some standard spec and allow client-side
languages to use the features you describe for the properties where that
makes sense, such as the more frequently used props, and those which are
cheap to generate and pass through the bus. It's just that in the case of
systemd there are more props where this does not make sense than
where it makes sense, to pass the data around gratuitously.

Well, I think I mentioned this elsewhere: I am concerned that you are
driving d-bus too much into a direction where it is only suitable for
your specific kind of high-level object environment, and losing those on
the way who use it on the lower levels and try to avoid the biggest
performance pitfalls.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4