KDE Geolocation Services
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
More information about the kde-core-devel