Semantics of o.fd.DBus.Properties

[Simon McVittie]

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

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

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

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

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

iD8DBQFHq3NrWSc8zVUw7HYRAvfNAKDc35Cs04GFoy0c7KETjlwj4y/sBgCgng/e
Wx/5H9euqgIoO0cwtqldBQs=
=3gaT
-----END PGP SIGNATURE-----