Properties interface enhancements

[Rob Taylor]

John (J5) Palmieri wrote:
> On Sat, 2007-12-08 at 21:57 +0100, Thiago Macieira wrote:
>> Simon McVittie wrote:
>>> Additions in our
>>> interface compared with D-Bus':
>>> * property permissions (read-only/write-only/read-write/completely
>>> unavailable)
>> How is that different from the D-Bus read-only, write-only and read-write 
>> properties?
>>
>> I'm ignoring completely unavailable properties because they are, by 
>> definition, unavailable and useless. Do you have a use-case for a 
>> property that always exists, but can't be read or written to?
>>
>>> method ListProperties () -> a{s(suv)}
>>>    (or a{s(guv)} if dbus-glib ever gets support for the 'g' signature)
>>>    Return a dict mapping property names to structs containing
>>>    (type signature, flags, current value). Output might look like:
>>>
>>>    { 'name': ('s', READ, 'Simon McVittie'),
>>>      'alias': ('s', READ|WRITE, 'smcv'),
>>>      'write-only-property': ('u', WRITE, 0),
>>>      'unimplemented-property': ('u', 0, 0) }
>>>    [0]
>> ListProperties => Introspect
>>
>>> method SetProperties (a{sv}) -> nothing
>>>    Set the given properties to the given values. Raise an error if one
>>>    of the given properties is set to a value of an inappropriate type
>>>    (for interoperability, integer types should be converted silently at
>>> the service end whenever necessary - blame dbus-glib) or if one of the
>>> given properties is not writeable.
>> Good idea. A method to set many properties at once, avoiding round-trips.
>>
>>> signal PropertiesChanged (a{sv})
>>>    Indicates that the given properties have changed. Services MAY emit
>>>    this signal with properties that have not, in fact, changed.
>>>    Services MUST emit this signal if the property has changed [1].
>>>    The parameter is a map from property names to new values.
>> This is what we're discussing.
>>
>>> signal PropertyFlagsChanged (a{su})
>>>    Indicates that the flags of the given properties have changed. The
>>>    parameter is a map from property names to the new flags [2].
>> I don't agree with this. Interfaces don't change while they're existing, 
>> so properties shouldn't change from readable to write-only, etc.
>>
>>> [0]: I believe the D-Bus XML introspection format is far from ideal, and
>>> if it's as easy as this to stop an interface from dependending on
>>> "introspection 1.0", we should.
>> Whereas I would agree that using D-Bus's own data structures to describe 
>> the interfaces would have been better in the beginning, now everyone 
>> parses the XML already.
>>
>> Besides, applications don't query unknown interfaces in unknown objects at 
>> run-time and decide by themselves what to do. They only talk to known 
>> interfaces, which means that the remote end's capabilities are known at 
>> develop- and compile-time. Pre-parsing an XML file at that point has 
>> negligible cost.
>>
>>> [1]: I realise this makes it impossible for D-Bus properties to map 1:1
>>> to Qt properties, but I don't think properties without change
>>> notification are likely to be very useful, particularly if you're trying
>>> hard (as we do) to avoid blocking on D-Bus calls. If others overrule me
>>> on this, we could introduce a third value for PropertyFlags,
>>> PROPERTY_FLAG_CHANGE_NOTIFICATION, meaning "changes to this property are
>>> guaranteed to have change notification" (or PROPERTY_FLAG_NEEDS_POLLING,
>>> with the opposite meaning).
>> This is Marcel's proposal: we add a flag to the property indicating if 
>> it's "watchable". I would personally like to avoid sending signals 
>> unnecessarily, so I'd request the signal be emitted only if there's at 
>> least one listener.
> 
> Well, this is how signals work though you still have one trip to the
> bus.  Are you proposing the client filter out signals that have not been
> connected to?  That is kind of hard to do given I could add a match
> which listens for all properties named 'myproperty' in which case do you
> tell all the clients?  Also there is a race there from the time it
> should emit the signal to the time it receives the message that is
> should be allowed to emit the signal.
> 

I've actually long though that this could be pretty useful - unnecessary
context switches aren't nice! (seriously, with this work to move AT-SPI
to dbus, it'd be good if every ATK signal emission didn't result in a
context switch when there's no AT's running). It'd be possible to remove
the race condition by having the bus only return from AddMatch after
it's informed all relevant connections of the new requirement (and got a
return from those calls).

I'm not sure what form the service-side interface would take though.

Thanks,
Rob

-- 
Rob Taylor, Codethink Ltd. -  http://codethink.co.uk