Properties interface enhancements (was: Signal for property changes)

[Marcel Holtmann]

Hi Simon,

> The short version: if you're augmenting or redesigning the Properties
> interface, please consider stealing ideas from Telepathy.

I don't wanna re-design it. I only wanna extend it with a signal that
indicates if a property has changed. Without that, the whole interface
is kinda useless for me. I can always design my own, but that is exactly
what we did before and it becomes too much effort to maintain a big list
of method that essentially only do set/get and notify.

> > I was playing with the idea of replacing most method calls of the BlueZ
> > API with the generic org.freedesktop.DBus.Properties interface.
> 
> We have a more extensive Properties interface in Telepathy, and in fact
> there's nothing Telepathy-specific about our interface - you could use
> org.freedesktop.Telepathy.Properties right now. Additions in our
> interface compared with D-Bus':
> 
> * change notification

The change notification is important for me. The rest of the D-Bus
properties interface is perfectly fine.

> * property permissions (read-only/write-only/read-write/completely unavailable)

Don't see an advantage here. Currently read/write and readwrite access
differentiation is already supported.

For the completely unavailable, I would use an error code. This would
bring me to another topic. What error codes should be returned for Get
and Set for the the different error cases. Like access denied or
property unavailable.

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

I don't have an issue with the introspection format. I could easily
extend the properties interface with a change notification signal. My
attempt is to do in a standard way that would be upstream approved.

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

I do also think that properties without change notification are useless,
but in some cases they might happen. As mentioned in the other email, we
can simply annotate the property and let it tell us if a change
notification signal is guaranteed.

> [2]: This may seem weird, but in fact we use it in Telepathy - for
> instance, when you become a moderator/admin/op in a chatroom, many of
> its properties become writeable. We also deny read permission on chat
> room properties until we've found out their values from the server.

Personally I don't need this right now, but it could be considered.
However this means you would invalidate the introspection information.
In a sense you do this today anyway when registering a new child path.

> Another thing we're pondering adding, which I think would be good to
> have in a "D-Bus properties interface 2.0", is a naming convention or
> naming rules for the properties themselves (I'm not sure whether this
> should be a non-binding convention, or some hard requirements).

I don't think that is needed. Properties are path and interface
specific.

Regards

Marcel