Semantics of o.fd.DBus.Properties

[Thiago Macieira]

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

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

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

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

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

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
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freedesktop.org/archives/dbus/attachments/20080207/546266e9/attachment.pgp