Properties interface additions

[David Zeuthen]

Hey,



On Tue, 2009-01-27 at 01:16 -0500, Havoc Pennington wrote:
> Hi,
> 
> 2009/1/14 David Zeuthen <david at fubar.dk>:
> > to indicate property changes. Of course this only works if the other end
> > is using EggDBus but for the projects I'm working on this happens the
> > case. Still, I'd like to propose that we add a Changed() signal to the
> > D-Bus specification. I've attached a patch for this. OK to commit?
> >
> 
> Just looking at NetworkManager 0.7, it has PropertiesChanged rather
> than simply Changed; while in theory signals are namespaced by
> interface, in many languages it might save some pain to call the
> signal PropertiesChanged. "Changed" seems like a common and useful
> signal name for all kinds of things.

I'm OK with just calling it PropertiesChanged.. but... since it belongs
to an interface, org.freedesktop.DBus.Properties, that people aren't
supposed to be messing with anyway (hence why EggDBus currently uses a
signal with the name EggDBusChanged) I'm in favor of just calling it
Changed because it's shorter.

> Is there some way to make it optional to send the new values with the
> changed signal? X properties for example do not. The issue is that the
> value could be large or large-ish. The basic question for an API
> designer would be whether several listeners will almost always want
> the value (better to send it), or only 1 or 2 will want it, or usually
> nobody wants it, and it's large (better not to send it).

It would be easy if we said a VARIANT could be empty, some kind of void
type (which would be useful in other situations too). But we don't
currently have that and I suppose adding a new data type to the protocol
would be a change that isn't backwards compatible, right?

We could also just change the signature of Changed to be

 signal Changed(STRING interface_name,
                DICT<STRING,VARIANT> changed_properties_with_values,
                ARRAY<STRING> changed_properties_without_values);

but that is just ugly and it would make life slightly more difficult on
the bindings. Maybe that's not a big deal though, I don't know.

A more practical answer is that if you are using properties in a way
such that change signals incur a performance penalty / storm of
Changed() signals then you simply don't use the Changed() signal at all.
That's why the patch to the specification says it's optional.

We could also play games with having a flag/annotation on each property
on whether changes to it will generate a Changed() signal or not. Or we
could have a property (which must not change itself) on the Properties
interface that says whether Changed() is supported at all. That way
bindings can do the right thing. I think the latter is probably the best
solution.

My personal view is that if you have these kind of problems, you
probably shouldn't use D-Bus properties in the first place. But that's
not really constructive. 

I guess a lot of this discussion really is about how people should be
using properties, e.g. I'm looking for a more concrete characterization
of properties in the D-Bus specification. Evidence does shows that
people use properties in very interesting ways that, I'd argue, violate
the spirit of D-Bus properties namely that they correspond to the
concept of object properties / attributes in native APIs (paraphrased
from the spec).

That said, I completely agree that we can't break existing users of the
org.freedesktop.DBus.Properties interface. Then again, I think it's
highly desirable to have some kind of Changed() signal; people are
rolling their own in various ways and this only makes things a lot
harder on app writers.

To keep the discussion going, here's a more concrete proposal

 1. Introduce a new readonly property 'SupportsChanged' of type 'as' on
    the org.freedesktop.DBus.Properties interface. This is a list of
    interface names for which Changed() will be emitted. The spec
    will guarantee that this property is won't change so bindings/
    apps exporting the interface will need to comply with that.

 2. Introduce a Changed() signal on org.freedesktop.DBus.Properties;
    basically the same as in my original mail.

If only we had sorted this before 1.0.... 

     David