On Sun, 2008-12-14 at 20:49 +0100, Marcel Holtmann wrote: > 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. Shouldn't any client-side complexity, if any, be handled by the client bindings, and thus be completely transparent to the author of the application that's actually using D-Bus? Certainly nobody in their right mind tries to talk to a D-Bus service using straight libdbus. Hence why there are like 30 different libdbus bindings that make things easier for app writers. It doesn't matter if the complexity is in the server or client side, the app writer shouldn't have to care about it, because it'll already be handled by the bindings (C, glib, or whatever) or the service. Thus, since it's no harder for the app writer to use the D-Bus properties interface, or the custom hand-rolled interface, the standard interface should be used. D-Bus exposes objects. Objects have properties. Making up a new method for accessing those properties is simply dumb when most of the client bindings (and clients) already support the existing standard. Dan
