On Thu, Nov 4, 2010 at 2:04 PM, John Layt <[email protected]> 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
