D-Bus server should speak the standard properties interface

Assuming this request is of practical benefit, does anyone have the knowledge and time to address it?

Yep, this refers to the D-Bus Freedesktop standard APIs http://dbus.freedesktop.org/doc/dbus-specification.html#standard-interfaces.

Looking at the way the ffado-dbus-server models the API, it's going to be difficult to add Freedesktop properties interface. The FFADO APIs export the 'properties' through getters:

getId() -> uint64
getLabel() -> string
getName() -> string

The Freedesktop API's would model this via properties. e.g.

GetAllProperties() -> 

[ "Id" : uint64,
  "Label": string,
  "Name": string ]

SetProperty?(key, value) for setting and property changed signals would go through PropertyChanged?(key, value).

The FFADO API has a also a property change signal called Updated().

So looking at the current API's, it is possible to model the API's more 'mainstream' but it will definitely break applications using the current API.

If this should be done, we should also think about side channel communication. Having a lot of those message on D-Bus is not a good idea. Side channels are the way to go if you have a lot of message to send (e.g. level values). See for example the current discussions on D-Bus optimizations http://lwn.net/Articles/484203/, http://blogs.gnome.org/rodrigo/2012/02/27/d-bus-optimizations/ http://blogs.gnome.org/rodrigo/2012/03/07/d-bus-optimizations-ii/.

Thanks for the info Wagi. So the practical upshot is that making FFADO conform to the freedesktop API ideals is going to be a lot of work and it will probably need to be done by someone who is familiar with dbus internals. So where does that leave us? My gut feeling is that at this stage it isn't worth spending time changing this since there are so many other things to do which will be of more benefit to a wider range of users. Of course if someone comes along with a patch which addresses this I've no objection to it going in; it's just that the core developers probably have enough things to do without adding a non-critical component rewrite to the equation.

What say others?

Perhaps we need to create a "non-critical" milestone (or some other designation - maybe a new type) to park tickets such as this for which there's no firm timeline but whose outcome would be useful non-the-less. That way they won't distract from the critical tickets but at the same time won't get lost in the system.

It doesn't appear that current developers see a need to pursue this ticket at present, and I would agree given the limited number of people currently working on FFADO. It would be great if someone were to come along and offer to work on this, so the priority and milestone have been set accordingly. This way the idea doesn't get lost. If after a year or so there have been no takers I suggest the ticket be closed as "wontfix", as this would clearly demonstrate that there no one considers this idea worth the time it would take to implement.