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