On Thursday, November 4, 2010, John Layt 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. > > 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.
so we'd have to reimplement the core functionality, which leaves us with just the geoclue API and the design done for us. the only way this would be a win, imho, is if geoclue was already widely deployed on the target system. for the desktop, that doesn't seem to be the case (though i do see some dependencies on it on my system: google gadgets, gtk's stupidely named libwebkit). to me, that's just another strike against using geoclue. we'd end up putting a layer on top of it to be future proof and gain portability. iow, what QtMobility's Location API is doing. > 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. that could be a hidden detail that wouldn't need to be exposed in the API? why does the API need to offer any control over the backend, versus have it configured at the system level? > 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? it doesn't seem to be a hard dep; there seem to be target-specific (e.g. maemo5, maemo6, symbian, etc) providers that get compiled in as appropriate. i just took a look at the install of it, and libQtLocation is also an independant library with no deps on other parts of QtMobility. it apparently builds on its own and installs on its own. (at least i was able to do that here. :) the Landmarks issues that Torsten raises seem valid. perhaps we should start talking with the people working on libQtLocation and see if we can't make this into exactly what we all need and want, as that seems like it could be the best route (excuse the pun ;) if we can get some things ironed out. as an aside, the fact that something in Qt *Mobility* is of interest to desktop, etc. just underscores for me how utterly naive the idea of "this is for mobile, this is for desktop, this is for.." is. yes, some GUI differences exist. but beyond that a computer is a computer and it's all one big spectrum of capabilities. QtMobility is a stupid label imho, as would a QtDesktop module be. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks
signature.asc
Description: This is a digitally signed message part.
