KDE Geolocation Services

[Vishesh Handa]

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>