Properties interface additions

[David Zeuthen]

On Wed, 2009-01-28 at 12:02 -0500, Havoc Pennington wrote:
> 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?

Multiple signals, one for each interface. We could change the Changed()
signal to fold this into a single signal.

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

In EggDBus there are both object and interface proxies so there are no
issues with member collisions; each interface is a separate GObject.

 EggDBusObjectProxy *object_proxy; 
 AcmeRocket *rocket;
 AcmeCoyote *coyote;

 object_proxy = egg_dbus_connection_get_object_proxy (session_bus,
                                                     "com.acme.Service",
                                                      "/roadrunner");
 rocket = ACME_QUERY_INTERFACE_ROCKET (object_proxy);
 coyote = ACME_QUERY_INTERFACE_COYOTE (object_proxy);
 g_object_get (rocket, "name", &rocket_name, NULL);
 g_object_get (coyete, "name", &coyete_name, NULL);
 g_signal_connect (coyote,
                   "notify::name",
                   G_CALLBACK (coyote_name_changed),
                   NULL);


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

Yeah, that sounds good to me. So it would be

 <property name="name" type="s" access="read" emits-changed="true"/>

Are consumers of introspection XML supposed to cope with a new attribute
popping up? I think they are... the spec doesn't say anything about this
(should we fix that?) but given the X in XML I think they are supposed
to.

Does that look OK?

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

Exporting a native object... it sounds so.. straightforward and
tempting. In reality it's not straightforward and properties will be the
least of your problems. I mean, do you run the methods in separate
threads or fibers, how do you handle errors, how do you get context
information about the caller and so forth.

So any export_native_object() method on a D-Bus binding library will
likely take a lot of flags/parameters to answer some of these questions.
You'd fold the property thing into this as well.

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

Or users can connect to the Changed() signal manually.

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

Right. It's useful to note that, to the designer of an interface, that
the Changed() signal is totally optional and opt-in. Nothing will stop
working.

     David