Semantics of o.fd.DBus.Properties
thiago at kde.org
Thu Feb 7 14:08:50 PST 2008
Simon McVittie wrote:
>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?
QtDBus supports any property name that is a valid C++ identifier (in
ASCII). That matches D-Bus member names.
A D-Bus property is mapped to a Q_PROPERTY, which must be defined in one
class derived from QObject. It must therefore have one or more
interfaces. Different QObjects or adaptors attached to the same D-Bus
object path can therefore have the same property name in different
interfaces, with completely different behaviours.
The same applies to method names and signals.
QtDBus also implements an extension to the Get and Set property calls: if
the interface name argument is empty, it'll try to find the first
property that matches the name. If there's more than one, behaviour is
undefined. (Right now, it finds the first interface alphabetically)
>> * 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.
QtDBus does not apply any transformations at all on any names. That means
that, for anyone using it to have D-Bus style names
(GetCamelCaseCapitalFirst), you have to write identifiers that stand out
from the rest of the API (which is generally
>> * 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.
Exceptions in Qt in general cause bad behaviour and application exit. It
would be a bad practice to throw from the method handler.
So it never fails in the sense that a call to Set always returns a
method-reply message, never a method-error. The Qt property mechanism
doesn't allow for failing anyways, so extending that might be difficult.
>> * 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
>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.
The method handler is allowed to determine if the value is acceptable or
not. That's the difference between a property and a plain, member
variable in C++: there's a function that receives the value and validates
So the called setter may decide to take no action or modify the value.
Like you said, normalise, lowercase, etc. Imagine a call to Set(name
= "percentage", value = "120") -- it can decide to bound that to 100%.
In other words, that is, the caller of Set MUST NOT assume that a
subsequent Get will return the same value.
>> * 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
It can't, not safely.
I am uncertain if you should assume that calling Set or Get always runs
code in the remote object.
>> * 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.
In Qt, this is not guaranteed by contract, but by common sense. The
property system is the same one that Qt Designer uses -- if that took 10
seconds to calculate, it would be unacceptable. Note that Qt Designer
even caches the values, which you can't do in D-Bus.
>> * 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.
I think this is an ill-defined statement. Any call in a multi-tasking
environment has its order of undefined relating to other calls.
What you should be able to guarantee is proper serialisation of messages.
I.e., proper Read-After-Write and Write-After-Write semantics. Whether
the first write in WAW is executed depends on whether arbitrary code is
If you mean that a call to Set should return within a short time to be
considered synchronous, then I agree by common sense.
In other words: if it's not supposed to be "instantaneous", it should be a
method, not a property. A property should be treated like the equivalent
of a "volatile" variable.
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freedesktop.org/archives/dbus/attachments/20080207/546266e9/attachment.pgp
More information about the dbus