>-----Original Message----- >From: meego-dev-boun...@meego.com [mailto:meego-dev-boun...@meego.com] >On Behalf Of ext Arjan van de Ven
>On 10/28/2010 6:10 PM, Sivan Greenberg wrote: >> Re reading about MeeGo's architecture, is Geoclue the engine or the >> "backend" for Qt's Mobility location and positioning APIs? >> >> If not, what is the relationship ? > > >geoclue is the reference back end. Geoclue however is not a manadatory >component. >It's very likely that some commercial implementations of MeeGo will have >their own custom back end, >especially to tie into location services (maps etc) that service >providers provide for a fee. Actually the devil is in the detail. From a Qt perspective Location covers four things: 1.) Positioning (get me the current coordinate 2.) Maps 3.) Navigation 4.) Landmarks/POIs Point 2-4 are based on plug-ins and can easily swapped out. With regards to positioning the Qt location actually integrates GeoClue into its own code base (and links against it). Swapping GoeClue out for positioning would therefore require a new backend inside the QtLocation library. Such positioning adaptations have to happen below/inside GeoClue (from a stack perspective). Not every Qt API consists of plug-ins as their backend. In general, that's only done if it is likely that the same device image should/could be extended/changed during the same device's lifetime (e.g. add more codecs, use a different maps provider etc). Otherwise a plug-in solution is too expensive for multiple reasons. The same applies to things like connman, ofono or other types of platform API's. Most Qt libraries with ties to those platform API's do not have a plug-in mechanism for their backends. -- Alex _______________________________________________ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
