On Thu, 2010-11-11 at 14:45 -0700, ext Wichmann, Mats D wrote: > [email protected] wrote: > > On Thu, Nov 11, 2010 at 01:27:44PM -0800, Andy Ross wrote: > >> The subject of how the "MeeGo API" is defined came up in the TSG > >> yesterday, and against my better judgement I managed to inject myself > >> into a discussion about standards. > >> > >> The way it's currently phrased, the MeeGo API is a very limited set of > >> libraries (Qt, QtMobility and GLES, plus the web framework). > >> Everything else is reserved for the "Platform API", which carries no > >> promise of future availability. > > > > I have just recently read the developer pages on this very > > subject, and I was surprised to find the distinction, that Meego Touch > > Framework and the Web Runtime are in a "Platform API" with > > warnings against using them. More clarification is indeed > > needed, as far as I am concerned. > > In the case of these two, it's a question of maturity. > Since the current versions aren't fully mature, it can't be promised > they won't change in the next version. There's nothing to prevent, > and indeed it's the intent, to promote these to high-guarantee status > once the right level of maturity is reached.
Actually this is not accurate. The mid term future of MeeGo Touch Framework and Web Runtime is not clear next to Qt / Qt Quick and HTML5. The components are in MeeGo 1.1 and the APIs are there for developers, but a good advice for new projects is to check Qt Quick first. About deeper APIs in the platform, the reason to push a well controlled set of APIs around Qt and Qt Mobility is not only based by the fact the components "will be there" in the future. It's also related to the possibility to manage the MeeGo API properly, offer a compatibility promise towards future releases, simplify the developer story, documentation, training materials... For the big majority of application developers targeting MeeGo, the Qt / Qt Mobility APIs should suffice (plus OpenGL ES for the specific segment willing to use it). If any of these developers is not finding what he is looking for, then bugs against Qt Mobility are welcome (I asked the maintainers and this is the answer they gave). The MeeGo Compliance needs to sit on a clear principle, and the MeeGo API described at http://meego.com/developers/meego-architecture/meego-architecture-api-view is clear. If the implementation of the principle has some problems today (functionality not covered by APIs, or APIs not connected the MeeGo backend) then we need to know what is missing and work on the implementation and fixes. Bypassing a problem by hooking directly on a deeper API solves a problem today, but still the bug reports are needed to help the Qt Mobility team working on the right items. -- Quim _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev
