Semantics of o.fd.DBus.Properties

[Matthew Johnson]

On Thu Feb 07 21:09, Simon McVittie wrote:

> 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

Sounds sensible

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

I'll note here that currently dbus-java does nothing specific about
Properties. The interface can always be manually implemented as a normal
interface by the  application author. I think this should count as
"complete" binding.s Having said that, it's on my TODO list (-:

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

Yes

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

Setting a property can return an error (and certainly will if that
application has just fallen off the bus. Applications should expect this
and so should be able to cope with more mundane errors like EINVAL).
It's IMO up to the interface semantics whether a value should be clamped
or throw an error. We could standardise some errors to throw, however.

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

See above.

> * 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 that in a lot of cases it's desirable if properties are very
simple, since they can be handled by built-in features of the bindings.
Implementing another level of callbacks etc seems a bit much. However,
as I said at the start, I imagine most of the time you'll be able to
supply a complete custom properties implementation if you want one.


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

I agree with Havoc that you should certainly say that once you have had
a reply to the Set call then you can expect Get to return the new value.
I don't think we should rely too much on the serialisation of messages,
since it restricts how they can be implemented.
-- 
www.matthew.ath.cx
D-Bus Java
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.freedesktop.org/archives/dbus/attachments/20080208/128be572/attachment.pgp