[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-core-devel
Subject: Re: KDE Geolocation Services
From: Vishesh Handa <handa.vish () gmail ! com>
Date: 2010-11-04 8:55:47
Message-ID: AANLkTimQmLJySKrFENMXo3ec3qHc2-9BWm8gcz7m5fU3 () mail ! gmail ! com
[Download RAW message or body]
On Thu, Nov 4, 2010 at 2:04 PM, John Layt <johnlayt@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
[Attachment #3 (text/html)]
<br><br><div class="gmail_quote">On Thu, Nov 4, 2010 at 2:04 PM, John Layt <span \
dir="ltr"><<a href="mailto:johnlayt@googlemail.com">johnlayt@googlemail.com</a>></span> \
wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px \
#ccc solid;padding-left:1ex;"> <div class="im">On Wednesday 03 November 2010 22:27:11 \
Aaron J. Seigo wrote:<br> <br>
> that said, what dependencies does Geoclue have these days? it used to<br>
> depend on gconf, which would be a highly unfortunate dependency for<br>
> kdelibs to acquire. it was said a few years (!) back that this dependency<br>
> would be easy to remove and would likely be. has it been?<br>
<br>
</div>Well, to be slightly clearer, the whole point of having our own phonon-like<br>
api would be that there would be no hard dependency on any backend, Geoclue or<br>
otherwise. No Geoclue installed, we try a different backend, perhaps having a<br>
default hostip fallback. If no backends are available (or can't determine<br>
your location) you get a null location.<br></blockquote><div><br></div><div>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.</div> <div><br></div><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex;"> <br>
I've had a poke around, and there still is a partial GConf dependency, but<br>
apparently only in the Master Provider:<br>
<br>
<a href="http://cgit.freedesktop.org/geoclue/tree/src/main.c" \
target="_blank">http://cgit.freedesktop.org/geoclue/tree/src/main.c</a><br> <br>
A quick explanation, Providers are the backends like gpsd or hostip that you<br>
can query for your location. You can choose to query any one of these<br>
directly, but the Master Provider implements logic to decide for you which is<br>
the best one to query. In theory, you don't need to install the Master<br>
Provider, or indeed any single Provider, if you don't want to (although I<br>
haven't checked how easy the build system makes this).<br>
<br>
In openSuse at least the Master Provider is packaged separately to libgeoclue<br>
and the the other Providers, allowing libgeoclue to rely 'only' on glib \
and<br> gobject, leaving the Master Provider to pull in gconf.<br>
<br>
This makes it possible for us to choose not to depend on the Master Provider,<br>
but the base library only, and implement our own Master Provider in our api.<br>
Our api would already have been deciding which backend to call, Geoclue or<br>
something else, it would now also have to choose which Geoclue backend to<br>
call. While it would make the api somewhat fatter than I had thought, it<br>
perhaps would be more flexible and future \
proof.<br></blockquote><div><br></div><div>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.</div> \
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex;"> <br>
With regards to the roll-our-own vs QtMobility option, I wonder what<br>
QtMobility's dependencies are? Is Geoclue a hard dependency, or does it also<br>
have its own Master Provider concept making Geoclue optional?<br>
<font color="#888888"><br>
John.<br>
</font></blockquote></div><br><br clear="all"><br>-- <br><font \
color="#999999">Vishesh Handa</font><br>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic