On Thursday 04 November 2010 09:01:12 Kevin Krammer wrote: > On Wednesday, 2010-11-03, Aaron J. Seigo wrote: > > a) annoyance of using DBus directly > > It's a single line in the CMakeLists.txt, isn't it? > > > b) changes in the DBus API are out of our control. > > Sure, but upstream API changes are always out of our control. > > Anyway, neither of these would impose a problem of having a Qt style API > for the service.
Sure, the DBus calls would return you the information you need, but I feel it would impose a higher level of knowledge on the app coder, they would have to understand Geoclue itself to know how to work it, set it up, call it, understand the returned data, then use it. It would also allow us to provide convenience classes for things like Coordinate, Location and Address that integrate and work properly, rather than having each app creating their own possibly buggy versions. It would also give us Qt-ish things, like nice signals passing a Location everytime a location changes. We'd then have only one place where we generate the QDbus adaptor instead of 50, only one copy of the template set-up/tear-down code instead of 50, and only one place that needs maintenance if/when Geoclue changes. [I do need to read more on how QDbus stuff works, I'll admit that :-)] It's more about making it easier for the coder than there being anything wrong with using DBus. Funnily enough, I went looking for examples of the DBus calls required for a simple location query, and even the Geoclue website doesn't provide any, they only show how to use the C interface. > > that said, what dependencies does Geoclue have these days? it used to > > depend on gconf, which would be a highly unfortunate dependency for > > kdelibs to acquire. it was said a few years (!) back that this dependency > > would be easy to remove and would likely be. has it been? > > This sounds weird. I have to admit I don't know anything about the Geoclue > architecture, but how would a service implementation detail become a client > dependency? > Do the D-Bus calls transport GConf keys? No, I understand it uses it for storing some internal config for the Master Provider, there's no GConf stuff in the dbus calls. In fact, I think it even provides a dbus api for changing the Provider config (which are not in GConf) which that Master Provider also responds to. So we wouldn't have to deal with GConf at all, it's just an implementation detail at their end, but also an added dependency we may not want, but is entirely optional is we're willing to write our own Master Provider. John. >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
