[Banshee-List] [RFC] DeviceKit[-Disks]-Sharp, ndesk.dbus, and the org.freedesktop.dbus.Properties interface

[Ben Gamari <bgamari foss gmail com>]

Hey all,

First, I would like to announce the initial release of managed
interfaces for DeviceKit[1] and DeviceKit-Disks[2] using the
ndesk-dbus[3] DBus implementation. This work is meant to be the first
step in moving Banshee's IPod support (i.e. podsleuth and ipod-sharp)
away from its current hal-based approach. Please pull down the branches
and critique them to your hearts' content. I'm not sure where the
correct place to host them is but hopefully they'll eventually end up on
some more permanant server. Both of these interfaces are probably still
a little rough, especially packaging-wise. My autotools-fu is quite
weak, thus if anyone sees any issues patches are certainly welcome.
There is also a (extremely) simple test accompanying both libraries.

Unfortunately, DeviceKit-Disks-Sharp is missing one critical feature:
working properties. It seems that the current implementation of
ndesk-dbus (an excellent library, by the way) is lacking native support
for the org.freedesktop.dbus.Properties interface. While I could have
filled in each of the properties with hand-coded implementations using
org.fdo.dbus.Properties directly, this seems like an incredible hack to work
around a horrible shortcoming in the otherwise very clean ndesk-dbus.

In light of this, I would like to start a discussion about how to add
org.fdo.dbus.Properties interface support to the ndesk-dbus library.
After reading over the dbus specification[4], it seems that the description
of org.fdo.dbus.Properties interface, while vague, is good enough for
writing an implementation. Moreover, with the recent work in DeviceKit,
it looks like the properties interface will soon have at least one
ubiquitous user so having this functionality will be more important than
ever.

Incorporating support for a new interface into an existing and
widely-deployed library like ndesk-dbus certainly has its challenges.
First and foremost, it ought not to break applications that rely on the
library's existing getter/setter behavior. While I am certainly no
expert on the workings of the library, it seems to me that something
like the following might be both workable, and sufficiently backward
compatible,


using NDesk.DBus;

[Interface ("org.test.interface")]
[PropertyStyle (PropertiesInterface)] // Set default property style
interface IDBusInterface {
	// These would use the org.fdo.dbus.Properties interface
	int PropertyOne { get; }

	// Occassionally we might need to override the inferred name
	[PropertyName ("property-two-name")]
	string PropertyTwo { get; set; }
	
	// This would use the current getter/setter scheme
	[PropertyStyle (GetterSetter)]
	bool PropertyThree { get; set; }
}


In my ignorant opinion, it seems that the hardest part of this approach
would be determining the name of the desired DBus property (dbus
property names seem to be in the form of "property-name" whereas I for
one use CamelCase for C# property names). It seems that a majority of
names could be inferred from a few simple heuristics (splitting up
CamelCase and underscore_naming with dashes, etc.) whereas the remaining
cases could be overridden with an attribute.

Are there any fundamental flaws in this solution? Is there some crucial
reason I have missed that explains why this functionality hasn't been in
the library from day-one? After you know the DBus property name it seems
like generating the proper org.fdo.dbus.Properties method invocations
should be pretty trivial.

I took a look at the ndesk-dbus code earlier today in hopes of cooking
up a preliminary patch but unfortunately my knowledge of MSIL is pretty
lacking and it seems this is how the proxy is generated. When there is
consensus on a solution, would someone with a few hours and some
knowledge of MSIL could take a stab at this?

Again, the hope is that this thread will start a discussion. The idea
proposed above is only one potential approach and is probably
horrendously awful. That being said, having a complete and clean DBus
implementation on C# is only going to increase in importance.  I already
have a reasonable start on porting podsleuth and ipod-sharp to DeviceKit
so once we have support for org.fdo.dbus.Properties incorporated, it
shouldn't be long until Banshee will have DeviceKit-based iPod-goodness
on Karmic desktops everywhere. After that, I'll just need to take a stab
at Banshee.HalBackend[5] and we'll be legacy-free (AFAIK).

Any questions, comments, proposals, assistance, or flames, would be
greatly appreciated. I hope everyone is doing well.

Cheers,

- Ben


[1] git://mw0.ath.cx/devicekit-sharp
[2] git://mw0.ath.cx/devicekit-disks-sharp
[3] http://www.ndesk.org/DBus
[4] http://dbus.freedesktop.org/doc/dbus-specification.html#standard-interfaces-properties
[5] http://svn.gnome.org/svn/banshee/trunk/banshee/src/Backends/Banshee.Hal/Banshee.HalBackend/