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) Regards, Jari > -----Original Message----- > From: ext Van De Ven, Arjan [mailto:[email protected]] > Sent: 15. syyskuuta 2010 15:50 > To: Palojarvi Jari (Nokia-MS/Tampere); Leibowitz, Michael; > [email protected]; Spencer, Bob; Saxena, Sunil; Poussa Sakari (Nokia- > MS/Helsinki); Ylinen Mikko.K (Nokia-MS/Tampere); Kost Stefan (Nokia- > MS/Helsinki) > Cc: [email protected] > Subject: RE: The role of Qt Mobility APIs in MeeGo OS (WAS: RE: [MeeGo- > dev] MeeGo Porting Guide available for reading) > > Geoclue is not an architectural component at this point in time. > > it's the reference implementation for location, and in the meego.com OS > it will be there, > but we explicitly allow people making products to replace it with > something else if they want to. > > > however this is specific to geoclue, not a generalization. > QtMobility is nice, but it is an abstraction of components below it. > While most applications > can use these abstracted APIs just fine and be dumb fat and happy, we > all need to realize that > there will be more advanced applications that will need a level of > deeper control. An example of such > area would be multimedia. > These advanced applications will not be "thousands", but these tend to > be the high profile ones that > make a device interesting rather than just boring "all the same". > > In the architecture team we've tried to identify areas where we think > this will happen, but also restricted > by "does the implementation have a history of being ABI compatible > between versions" to minimize the pain > of going past the high level API. > > > > -----Original Message----- > > From: [email protected] [mailto:[email protected]] > > Sent: Wednesday, September 15, 2010 12:25 AM > > To: Leibowitz, Michael; [email protected]; Spencer, Bob; Saxena, > Sunil; > > Van De Ven, Arjan; [email protected]; [email protected]; > > [email protected] > > Cc: [email protected] > > Subject: The role of Qt Mobility APIs in MeeGo OS (WAS: RE: [MeeGo- > dev] > > MeeGo Porting Guide available for reading) > > > > I _currently_ see this quite differently. The attached picture > explains > > my views. Applied to this case, GeoClue defines the platform / core > OS > > level APIs and would need to be supported in any MeeGo compliant > device > > that supports location services. The Qt Mobility API back-end would > be > > written on top of GeoClue APIs. > > > > The other way (that Michael is proposing) to handle this is that Qt > > Mobility APIs effectively become full members of the MeeGo core OS. > So > > SW components in the core OS level would also use Qt Mobility APIs to > > access location services if they need them. And GeoClue would become > > something that vendors could use in their devices if they wish (would > > be fully optional). > > > > But if we move in this direction, then e.g. the Sensor Framework vs. > Qt > > Mobility sensor APIs question is analogous to this (and I guess there > > are other examples as well). > > > > I think that this is a pretty important generic architectural > question > > in MeeGo OS and would appreciate guidance from Arjan and other MeeGo > > architects. Technically both options can be made to work. The main > > difference is in what kind of dependencies we create into MeeGo OS. > > > > Regards, Jari > > > > > -----Original Message----- > > > From: ext Michael Leibowitz [mailto:[email protected]] > > > Sent: 13. syyskuuta 2010 21:11 > > > To: Carsten Munk; Spencer, Bob; sunil.saxena > > > Cc: Palojarvi Jari (Nokia-MS/Tampere); [email protected] > > > Subject: Re: [MeeGo-dev] MeeGo Porting Guide available for reading > > > > > > On Mon, 2010-09-13 at 11:09 -0700, Carsten Munk wrote: > > > > 2010/9/13 Michael Leibowitz <[email protected]>: > > > > > On Fri, 2010-09-10 at 05:07 -0700, [email protected] > > wrote: > > > > >> I’ve now spent some more time creating content to the MeeGo > > > Porting > > > > >> Guide (http://wiki.meego.com/MeeGo_Porting_Guide). > > > > > > > > > > "The MeeGo location architecture is based on GeoClue." > > > ... > > > > We need to update http://meego.com/developers/meego-architecture > > > then.. > > > > > > We sure do. > > > > > > Cheers > > > > > > -- > > > Michael Leibowitz <[email protected]> _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev
