KDE Geolocation Services

[Aaron J. Seigo]

On Thursday, November 4, 2010, John Layt wrote:
> 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.

so we'd have to reimplement the core functionality, which leaves us with just 
the geoclue API and the design done for us. the only way this would be a win, 
imho, is if geoclue was already widely deployed on the target system. for the 
desktop, that doesn't seem to be the case (though i do see some dependencies 
on it on my system: google gadgets, gtk's stupidely named libwebkit).

to me, that's just another strike against using geoclue. we'd end up putting a 
layer on top of it to be future proof and gain portability. iow, what 
QtMobility's Location API is doing.

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

that could be a hidden detail that wouldn't need to be exposed in the API? why 
does the API need to offer any control over the backend, versus have it 
configured at the system level?

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

it doesn't seem to be a hard dep; there seem to be target-specific (e.g. 
maemo5, maemo6, symbian, etc) providers that get compiled in as appropriate.

i just took a look at the install of it, and libQtLocation is also an 
independant library with no deps on other parts of QtMobility. it apparently 
builds on its own and installs on its own. (at least i was able to do that 
here. :)

the Landmarks issues that Torsten raises seem valid. perhaps we should start 
talking with the people working on libQtLocation and see if we can't make this 
into exactly what we all need and want, as that seems like it could be the 
best route (excuse the pun ;) if we can get some things ironed out.

as an aside, the fact that something in Qt *Mobility* is of interest to 
desktop, etc. just underscores for me how utterly naive the idea of "this is 
for mobile, this is for desktop, this is for.." is. yes, some GUI differences 
exist. but beyond that a computer is a computer and it's all one big spectrum 
of capabilities. QtMobility is a stupid label imho, as would a QtDesktop 
module be.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20101104/e79e95f0/attachment.sig>