Semantics of o.fd.DBus.Properties

[Havoc Pennington]

Hi,

Some .02 but I'm not sure I know the answers here better than anyone else.

On Feb 7, 2008 4:09 PM, Simon McVittie <simon.mcvittie at collabora.co.uk> wrote:
> 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.

In general I would say the issues here are the same as for methods.
Properties are largely equivalent to a setter and a getter.

> 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 think this is a problem with the GLib bindings. My view is that a
GObject that implements a dbus interface would normally be written for
that purpose (i.e. I don't believe arbitrary GObject would normally be
exported). But also there should be some mechanism to exclude signals
and props that should not be exported.

> This also prevents APIs that have the same property name in multiple
> interfaces, which is obviously undesirable.

The same name in multiple interfaces (whether for properties or
methods) I think can be expected to cause problems for at least some
bindings almost always; while we did not ban it on the dbus protocol
level, I would not say it's advisable to create the situation when it
can be helped.

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

I know we discussed this in some detail in the past, iirc we maybe
wanted a standard way to do change notification, but then in the
introspection data there would be a flag for whether a particular
property supported it, or something like that? (Or did we just decide
no change notification?) I think there was clear consensus that change
notification cannot be assumed for all properties.

> * Every implementation of (the same version of) an interface has the
>   same properties with the same access rights

Yes. If you think of properties as equivalent to a setter and getter,
props can't be omitted any more than a method could be.

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

Yes.

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

As an aside, the spec, in general, says pretty much nothing at all
about bindings - what it does say is pure guideline. There may be a
role for some kind of separate "how to do a binding" / "how to be
interoperable" spec, or section in the current spec.

I think in practice, people will avoid these property collisions
because for most bindings they will be annoying at minimum, and in
some bindings impossible.

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

This sort of thing is valid protocol, just as it would be for methods,
but I do think a binding could get away without supporting it. If only
because nobody will really do this, or if they do, everyone will mock
them and make them change it.

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

Anything that's IPC to another process can end up returning an
error... but I assume you mean something like, can a property have
invalid values.

I would say yes... I mean, very few properties I can think of accept
arbitrary values of the given type. So, perhaps we should specify some
type of error in this case, or perhaps we should say the value will be
silently clamped/ignored.

What do most languages do? I would guess that C# throws an exception,
I think GObject would usually g_return_if_fail() or else silently
clamp.

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

Agreed that few properties actually allow all correctly typed values.

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

I think so (cf. though the comments above about errors)

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

I would say Get is expected to be fast, but if someone wanted to make
it slow that would be more an implementation quality issue than a spec
issue.

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

If I do a Set then a Get, I would expect the Set to have taken effect.
(Maybe it was clamped or threw an error, but I would expect whatever
the Set is going to do, it has already done.)

A looser semantic would be that if I do a Set, block for reply or
error, then a Get, I would expect it to have taken effect. I think
this one for sure is required or it would just be insanity.

But, I think most apps would end up buggy/confused without the tougher
semantic that Set followed by Get has the expected result, even
without blocking for the Set reply first.

Havoc