Hi Dan, > > > > > One general comment before I go through it in more detail. The methods > > > > > dealing with Properties are redundant, since there's a standard D-Bus > > > > > interface specification for object properties. Check out: > > > > > > > > > > http://dbus.freedesktop.org/doc/dbus-specification.html > > > > > > > > the reason why I am for example not using the property standard in BlueZ > > > > is because dbus-glib is the most braindead implementation of it all. > > > > > > So what does dbus-glib have to do with it? Nothing. Whatever code > > > implements this will do so in the manner it likes, using dbus-glib, > > > libgdbus, eggdbus, or one of the other zillion libdbus rewrites out > > > there. Doesn't matter. > > > > > > It's simply pointless to use something else. Don't do it. It's a PITA. > > > Use the standardized interfaces. > > > > yeah, but I think a little bit about the languages and the bindings that > > are actually using these interfaces. The goal is to make their life more > > simple than complicated. The simpler the usage of these interfaces is > > for the actual client application, the better. > > Yeah, but "simpler" does not mean making up a whole new interface when a > perfectly good one already exists. You'll already have the proxy for > the object, so it's not like another bus round-trip is needed. The fact > that an object implements the properties interface is provided in the > introspection data. If the client bindings that apps are using don't > allow the properties interface to be easily used, then the client > bindings need to be fixed. making up a new interface makes no difference here. In both cases you actually have to implement it. So only advantage is the dbus-glib maps its properties to D-Bus properties. However as mentioned that is for the server side only. And I don't really care how nice and easy it is for the daemon to expose anything. The client usage of the API should be simple and with the current D-Bus properties it is not. At least in lowlevel C, GObject based GTK+ or Python there is no simple way of using D-Bus properties. You have to do everything by yourself. If you do that anyway, then you can also call a method in the interface itself. Same same. > Most other stuff that uses properties uses the standard interfaces. > What is so special about this interface that it needs to be different? There is nothing special about it and in fact it is quite simple to support both ways without breaking anything. However unless a property changed signal is defined in the standard, it is a useless interface to me that only imposes overhead in the client applications. And I am quite happy to admit that my reasons for not using D-Bus properties are purely based on the client bindings, but again, that is the whole point. Move the complexity into the daemon and make it really simple for the clients. Regards Marcel
