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