Semantics of o.fd.DBus.Properties

[Daniel P. Berrange]

A few notes on how I deal with this in Perl bindings...

On Thu, Feb 07, 2008 at 09:09:00PM +0000, Simon McVittie wrote:
> 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?

The Perl bindings support this, though its easier for people if all the
property names are unique.  Normally you can just acess the property
directly from the object

    $obj->SomeProp($newval)

or

    $val = $obj->SomeProp()

NB, properties here are in same namespace as method names too. If you 
have a clash between a property name & a method name you have to go the
long way and directly call the 'Set' and 'Get' methods to access the 
property

    my $props = $obj->as_interface("org.freedesktop.DBus.Properties");
    $props->Set("org.example.Blah", "SomeProp", $newval);
    $val = $props->Get("org.example.Blah", "SomeProp");

Similarly if an object has interfaces with clashing property names you
have to access it via the interface

    my $interface1 = $obj->as_interface('org.example.Blah');
    $val1 = $interface1->SomeProp()

    my $interface2 = $obj->as_interface('org.example.Wibble');
    $val2 = $interface2->SomeProp()

So life is much simpler if you don't have clashing property / method
names, but we can cope with any combination.

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

For sake of interoperability I'd say yes - though perhaps restricted to the
indirect access method of calling Set/Get on the org.freedesktop.DBus.Properties
interface directly, rather than binding specific syntactic sugar

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

Any & all calls can fail in the Perl impl.

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

Since the signature is a variant the app providing the remote object will
have to validate and accept/reject as appropriate. With a object provided
by a loosely typed language like Perl you can feed pretty much any data type
and the remote object will just interpret it as needed, but static languages
I'd expect to be more strict.

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

I'd expect they're synchronous, but since properties can be changed at any
time either by the service or other client, you can't expect that doing
Set followed by Get will get back the value you put in 

Dan.
-- 
|=-            GPG key: http://www.berrange.com/~dan/gpgkey.txt       -=|
|=-       Perl modules: http://search.cpan.org/~danberr/              -=|
|=-           Projects: http://freshmeat.net/~danielpb/               -=|
|=-   berrange at redhat.com  -  Daniel Berrange  -  dan at berrange.com    -=|