Properties interface additions

[Havoc Pennington]

Hi,

On Wed, Jan 28, 2009 at 11:30 AM, David Zeuthen <david at fubar.dk> wrote:
> 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.

Well, there are definitely GObject out there with a "changed" signal,
and probably some existing dbus interfaces too. What does EggDBus do
if the same object path has "changed" signal on two different
interfaces? How do you deal with that?

In practice with most bindings, I think collisions among members
within the same object are a big pain, even though in some perfect
universe the interface namespaces them.

> 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?

It could be made compatible through some sort of feature negotiation,
but I'd say it's a world of pain best avoided, unless you find
yourself with a lot of free energy to invest ...

> 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.

It seems relatively clean to me, if we already have read vs. readwrite
in the introspection, to also have there an emits-changed flag?

> 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 can certainly imagine cases where it's handy to have a native object
with a lot of attributes, and just stick it on dbus with readable
props, but no change notification.

> 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).

Well, many of the native API property systems don't have change
notification (e.g. QObject, JavaBeans, and I'm not sure about C#)

A thing about the "changed" signal, it won't be implementable very
cleanly in those bindings where objects don't have change notification
on attributes. They'll have to provide methods that emit the change
notification "by hand"

>  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.

Why not use the introspection for this, introspection is already
needed to know whether there's a setter for the prop or just a getter,
and to know what props there are...

Whether changed gets emitted I think is a feature of the interface; if
an API uses change notification, then all implementors and users of
that API must use it.

Havoc