KDE Geolocation Services

[John Layt]

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.