Hi Min, The Location API actually uses ifdefs to switch between the different platform-specific backends. There's been some confusion about this since we got some vague second-hand feedback about demand for plugins, but we haven't gone down that path since we've received pretty much zero indication that anyone actually wants them. If anyone has a strong use case for positioning plugins let me know :)
The Maps and Navigation API (which adds extra scope for confusion as it is part of the Location API) uses plugins - I believe that's what the porting guide is referring to although it's probably vaguer than it should be on what has plugins and what doesn't. Cheers, Dave > -----Original Message----- > From: [email protected] [mailto:[email protected]] > On Behalf Of Shin Minjung (Nokia-MS-Qt/Brisbane) > Sent: Thursday, 16 September 2010 3:00 PM > To: [email protected]; [email protected] > Subject: Re: [MeeGo-dev] The role of Qt Mobility APIs in MeeGo OS (WAS: > RE: MeeGo Porting Guide available for reading) > > Hi, > > The primary goal of Qt Mobility API is to provide useful mobile > functionalities to the application developers. So let's make it clear > that Mobility should not be considered as a means of Qt-ifing every low > level APIs. :) > > Regarding Location API, Location API has a plugin system for the > backends, so it does not enforce anyone to use only one backend. MeeGo > porting guide has some more information. > http://wiki.meego.com/MeeGo_Porting_Guide#Location > > Regards, > Min > > -----Original Message----- > From: [email protected] [mailto:[email protected]] > On Behalf Of ext Thiago Macieira > Sent: Thursday, 16 September 2010 7:36 AM > To: [email protected] > Subject: Re: [MeeGo-dev] The role of Qt Mobility APIs in MeeGo OS (WAS: > RE: MeeGo Porting Guide available for reading) > > On Wednesday 15. September 2010 20.42.40 [email protected] > wrote: > > Standardizing a low(er) level C API to each middleware level > “service” > > in MeeGo OS would have two benefits: > > > > - A single Qt Mobility API backend implementation would suffice > > => no need for vendor specific implementations > > > > - There would be a standard way to integrate middleware level > > SW components via C APIs => less need for vendor specifics > > in the middleware level (C++ APIs such as the Qt Mobility > > APIs are somewhat hard to use from C so middleware components > > written in C will typically use some other integration routes) > > And a drawback: > > - it's another level of indirection and abstraction, introducing > potential delays and complexity (translating information from one > format to another) and it's also a source of potential bugs. > > I'm not saying the middlewares are of bad quality. Not at all. > > But I don't want to see a middleware be written and added just because > none existed before. A middleware has to have a reason to exist, a > value to add. > > -- > Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org > Senior Product Manager - Nokia, Qt Development Frameworks > PGP/GPG: 0x6EF45358; fingerprint: > E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 > _______________________________________________ > MeeGo-dev mailing list > [email protected] > http://lists.meego.com/listinfo/meego-dev _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev
