KDE Geolocation Services

John Layt johnlayt at googlemail.com
Thu Nov 4 14:00:10 GMT 2010

On Thursday 04 November 2010 08:54:55 Vishesh Handa wrote:
> 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.

Yes, but we have no control over what Geoclue does, no guarantee that their 
api will stay stable over our support cycle (it is a fairly new project, so 
liable to change), or that they won't introduce further dependencies that we 
don't want, e.g. GConf, etc.  If Geoclue breaks, our api is still safe.

Even Qt has implemented their own wrapper in the form of QtMobility, so it's 
not unreasonable to do so.  Most of our api would just be a consistent and 
convenient wrapper around a QDbus abstract interface returning our convenience 
classes for location and address, so would add very little overhead.

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

Yes, ideally we'd just use theirs, but that may not be an option due to GConf 
use.  If we don't use Geoclue at all, then we'd have to write everything from 
scratch anyway, so it's still better than that.  Plus, theirs is marked as 
experimental still.


More information about the kde-core-devel mailing list