KDE Geolocation Services

Vishesh Handa handa.vish at gmail.com
Thu Nov 4 08:54:55 GMT 2010

On Thu, Nov 4, 2010 at 2:04 PM, John Layt <johnlayt at googlemail.com> 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.

Isn't the whole point of Geoclue to provide a telepathy-like-abstraction of
location providers?  ( or phonon like :) What huge advantage would there be
in implementing yet another abstraction on top of Geoclue? Apart from the
fact that you would still get your location without Geoclue.

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

So, you'd basically be doing what Geoclue's master provider is doing, but
without the additional dependency. Seems like loads of effort, but then it
would be 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.

Vishesh Handa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20101104/03024fe6/attachment.htm>

More information about the kde-core-devel mailing list