Semantics of o.fd.DBus.Properties
simon.mcvittie at collabora.co.uk
Thu Feb 7 13:09:00 PST 2008
-----BEGIN PGP SIGNED MESSAGE-----
I'm currently evaluating org.freedesktop.DBus.Properties for possible
use in Telepathy, as a way to avoid writing a million GetFoo() methods.
What are the thoughts of the core/binding authors on the semantics of
that interface? I'm particularly interested in the opinions of Havoc (or
whoever put Properties in the spec), and Thiago (because of Qt).
The specification just says "Many native APIs will have a concept of
object properties or attributes", which is a somewhat unhelpful description -
native object-system APIs have different semantics for properties
(including such fundamental things as possible names) and that's the
sort of thing D-Bus is meant to avoid in the name of interoperability.
dbus-glib has taken that concept and run with it, to the extent that a
D-Bus property called, say, "com.example.Anything.BongHits" (with any
interface!) is automatically and unavoidably mapped to the "bong-hits" GLib
property. This is rather ludicrous as a basis for an interoperable
properties system. I haven't tried, but I suspect you can cause many
GLib services to assert via this mechanism, which is somewhat unhelpful.
This also prevents APIs that have the same property name in multiple
interfaces, which is obviously undesirable.
Thankfully, dbus-glib doesn't apply special magic on the client side
(you just call the methods as normal), which I think is the way forward.
I'm not sure what QtDBus does in this respect, but dbus-python knows nothing
Having thought some more about this since the thread about properties
started by one of the BlueZ guys, I've come to the conclusion that the
Telepathy.Properties interface is not a useful model for this sort of
property - its semantics and those of DBus.Properties are fundamentally
different, and it has exactly two use-cases so far, of which one could
be done with DBus.Properties instead. So I'm not pushing for changeable
property attributes being part of DBus.Properties.
I'm also now of the opinion that DBus.Properties doesn't really need
change notification - while change notification is A Good Thing, not all
interfaces will want it (and not all implementations *can* implement it
reliably), so interfaces that want to mandate change notification can
each have their own PropertiesChanged signal that applies only to their
These things seem to be implicitly true of Properties, by virtue of
their presence in Introspect, but feel free to contradict me on them:
* Every implementation of (the same version of) an interface has the
same properties with the same access rights
* In particular, every implementation of an interface has *all* the properties
specified for that interface, and all of them (that are readable) have
some sort of value
In addition, how many of these assumptions are people making, and how many
should we codify in the spec?
* Are "complete" bindings required to support properties of the same name
in different interfaces?
* Are "complete" bindings required to support properties whose name is any
valid D-Bus member name? (e.g. "__IAm____OnCrack")
* Is it true that setting a property can never fail? (My opinion: no, it
can fail, and clients must not assume it will succeed)
* Is it true that all properties must accept *all* correctly-typed values?
(My opinion: no, it can fail, e.g. rejecting non-ASCII strings, or it can
quietly "normalize" values, e.g. forcing strings to lower-case)
* Can specification writers assume that services using "complete" bindings
will be able to run arbitrary code in response to a property being set?
Can they assume that that code will be able to alter the value to which
the property is set? Can they assume that that code will be able to cause
failure of Set() with a specified exception?
* Is it true that in the service implementation, readable properties are
always gettable synchronously and with no delay? (My opinion: must be,
otherwise GetAll loses totally - which means Properties are only
suitable for "locally cached" things)
* Is it true that in the service implementation, writable properties are
always set synchronously? (My opinion: don't know...)
-----BEGIN PGP SIGNATURE-----
-----END PGP SIGNATURE-----
More information about the dbus