This is my view, too. Basically the key point of GeoClue would be to offer an agreed (low level) C API to the location services in MeeGo OS. The Qt Mobility location API back-end could be written on top of that but would not have to be (e.g. if that would be an issue from performance perspective). So in addition to requiring support for the Qt Mobility location API, we'd be requiring GeoClue API support as well.
But, enough said about that. Regards, Jari P.S. the Sensors section in the MeeGo Porting Guide still states that the assumed HW adaptation interface is a Sensor Framework plugin interface. If someone sees this differently, please let me/us know... > -----Original Message----- > From: [email protected] [mailto:[email protected]] > On Behalf Of Shin Minjung (Nokia-MS-Qt/Brisbane) > Sent: 16. syyskuuta 2010 08:00 > 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
