[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: KDE Geolocation Services
From:       John Layt <johnlayt () googlemail ! com>
Date:       2010-11-04 8:34:44
Message-ID: 201011040834.44633.johnlayt () googlemail ! com
[Download RAW message or body]

On Wednesday 03 November 2010 22:27:11 Aaron J. Seigo wrote:

> 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?

Well, to be slightly clearer, the whole point of having our own phonon-like 
api would be that there would be no hard dependency on any backend, Geoclue or 
otherwise.  No Geoclue installed, we try a different backend, perhaps having a 
default hostip fallback.  If no backends are available (or can't determine 
your location) you get a null location.

I've had a poke around, and there still is a partial GConf dependency, but 
apparently only in the Master Provider:

http://cgit.freedesktop.org/geoclue/tree/src/main.c

A quick explanation, Providers are the backends like gpsd or hostip that you 
can query for your location.  You can choose to query any one of these 
directly, but the Master Provider implements logic to decide for you which is 
the best one to query.  In theory, you don't need to install the Master 
Provider, or indeed any single Provider, if you don't want to (although I 
haven't checked how easy the build system makes this).

In openSuse at least the Master Provider is packaged separately to libgeoclue 
and the the other Providers, allowing libgeoclue to rely 'only' on glib and 
gobject, leaving the Master Provider to pull in gconf.

This makes it possible for us to choose not to depend on the Master Provider, 
but the base library only, and implement our own Master Provider in our api.  
Our api would already have been deciding which backend to call, Geoclue or 
something else, it would now also have to choose which Geoclue backend to 
call.  While it would make the api somewhat fatter than I had thought, it 
perhaps would be more flexible and future proof.

With regards to the roll-our-own vs QtMobility option, I wonder what 
QtMobility's dependencies are?  Is Geoclue a hard dependency, or does it also 
have its own Master Provider concept making Geoclue optional?

John.
[prev in list] [next in list] [prev in thread] [next in thread]