Semantics of o.fd.DBus.Properties

Simon McVittie simon.mcvittie at collabora.co.uk
Thu Feb 7 13:33:17 PST 2008


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, 07 Feb 2008 at 21:09:00 +0000, Simon McVittie wrote:
> 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.

I should point out that since dbus-glib isn't very mature, we may be
able to fix this (possibly even in a mostly-backwards-compatible way).

Judging by the Qt docs:

> * Are "complete" bindings required to support properties of the same name
>   in different interfaces?

GLib doesn't, Qt probably does (each interface is a different QObject,
generally). Thiago: am I right?

> * Are "complete" bindings required to support properties whose name is any
>   valid D-Bus member name? (e.g. "__IAm____OnCrack")

GLib sort of does (it will mangle that name to "-i-am-on-crack" or
something, creating ambiguity with e.g. "_IAmOnCrack"). Qt does.

> * Is it true that setting a property can never fail? (My opinion: no, it
>   can fail, and clients must not assume it will succeed)

In both GLib and Qt it can never fail, unless the setter in Qt is
allowed to throw exceptions.

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

In GLib all values are currently "accepted", although some can cause
warnings, but arbitrary code is run and can do normalization.

In Qt all values are accepted (but perhaps the setter can raise an
exception? Thiago?) but arbitrary code is run and can do normalization.

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

In GLib and Qt arbitrary code runs and can alter the value arbitrarily.
In GLib it can't cause an error, in Qt it's unclear to me whether it can.

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

In both Qt and GLib this is true.

> * Is it true that in the service implementation, writable properties are
>   always set synchronously? (My opinion: don't know...)

In both Qt and GLib this is true.

    Simon
-----BEGIN PGP SIGNATURE-----

iD8DBQFHq3kdWSc8zVUw7HYRAgfCAKCLF7zXecNwQz/4/kDE8w1YNeO0iQCfYwhs
qYHoKC/yIZy45wGLzVO/GbY=
=kgVB
-----END PGP SIGNATURE-----


More information about the dbus mailing list