[MeeGo-dev] MeeGo vs. Platform API ambiguity
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 made the point that a literal reading here would make applications that link against the POSIX.1 symbols noncompliant. The answer came back that glibc was an obvious candidate for the MeeGo API, and didn't need to be specified. And for the C library I suppose that's true. But I think the issue is a more complicated spectrum than that. What about other useful APIs that are always present for a Qt app on linux? Is an app directly linking to zlib compliant (I don't think Qt wraps this)? How about libjpeg (which is abstracted by the framework)? What about an app which executes a shell script; can we assume a /bin/sh (or /bin/bash) will be present? What about a shell script that invokes tar or bzip2? I can understand the need for excluding a bunch of low level facilities that may be deprecated in the future, and limiting what constitutes MeeGo for forward-portable applications. But the way it's done right now rules out a lot of stuff that I don't think was intended. Is it worth going through the core package list more carefully and expanding the MeeGo API definition? Andy -- MTS, MeeGo Solutions, Wind River Systems andy.r...@windriver.com ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] MeeGo vs. Platform API ambiguity
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. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] MeeGo vs. Platform API ambiguity
meego-dev-boun...@meego.com 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 made the point that a literal reading here would make applications that link against the POSIX.1 symbols noncompliant. The answer came back that glibc was an obvious candidate for the MeeGo API, and didn't need to be specified. And for the C library I suppose that's true. But I think the issue is a more complicated spectrum than that. What about other useful APIs that are always present for a Qt app on linux? Is an app directly linking to zlib compliant (I don't think Qt wraps this)? How about libjpeg (which is abstracted by the framework)? What about an app which executes a shell script; can we assume a /bin/sh (or /bin/bash) will be present? What about a shell script that invokes tar or bzip2? I can understand the need for excluding a bunch of low level facilities that may be deprecated in the future, and limiting what constitutes MeeGo for forward-portable applications. But the way it's done right now rules out a lot of stuff that I don't think was intended. Is it worth going through the core package list more carefully and expanding the MeeGo API definition? I expect you'll get divided opinions on that, let's see what the reactions are. For me, we should identify stuff that's truly useful, and stable, and promote it to first class status. But I think there is a constituency that believes program to Qt and as an emergency exception if Qt doesn't wrap that yet there are a few other things you maybe could use - for now. And yes, you're allowed a shell script; tar/bzip2 don't appear to be in the package list (bzip2-libs is) though. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] MeeGo vs. Platform API ambiguity
meego-dev-boun...@meego.com 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. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] MeeGo vs. Platform API ambiguity
On Thu, 2010-11-11 at 14:45 -0700, ext Wichmann, Mats D wrote: meego-dev-boun...@meego.com 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 MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] MeeGo vs. Platform API ambiguity
On Thu, Nov 11, 2010 at 10:45 PM, Wichmann, Mats D mats.d.wichm...@intel.com wrote: 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. Nope, the decision to have these as platform APIs instead of MeeGo APIs is a strategic choice: http://www.engadget.com/2010/10/21/nokia-refines-development-stategy-adopts-html5-in-qt-and-ends-s/ Articles like these may seem a bit weird to technical people (with all the talk about 'Qt'), but when you replace all references to Qt with Qt Quick (which is the real meaning behind the message), they suddenly make more sense. Orbit was axed and MTF won't be promoted to external developers. Regarding WRT - having it as platform api is not an accident or oversight. -- Ville M. Vainio @@ Forum Nokia ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] MeeGo vs. Platform API ambiguity
On 11/11/2010 01:43 PM, Wichmann, Mats D wrote: I expect you'll get divided opinions on that, let's see what the reactions are. That's exactly my worry. But it seems that if we're going to go there (to a world where MeeGo means a limited and focused API suite and not just another distro), it's important to get it right ahead of time and not rely on intuition. My fear is that going ahead with the current API set is going to mean a ton of assumed compatible apps which dependencies on stuff that other people want to drop or change. Basically, everyone's intuition of what an obvious set of base features is will be different. FWIW, here's mine. I just quickly went through the list of MeeGo base packages in the current compliance spec and pulled out a list of the ones that provide important and common capabilities that I don't see abstracted in the current API set (or where I see a compelling reason to not want to use a wrapper API): bash bzip2 coreutils curl glibc gnupg grep openssl pcre sed zlib Andy -- MTS, MeeGo Solutions, Wind River Systems andy.r...@windriver.com ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] MeeGo vs. Platform API ambiguity
On Thursday 11 November 2010 22:15:26 Quim Gil wrote: 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). It depends on what you mean by application. If you mean the sort of apps that you find in the Apple iStore or on Ovi then I agree: the majority of app developers have what they need in Qt (although there is a substantial minority who need platform APIs as well -- even 10% would be a lot of developers). On the other hand, I don't agree that it is true for the large applications that don't exist in the handset world today but which many people are working on (like the mobile device equivalent of application suites routinely found on PCs such as MS Office/OpenOffice or Kdepim, or social network integrators, or augmented reality experiences and more). Those sorts of applications are multi-faceted and will build on many libraries of their own and others, require carefully tuned databases, specialised backup and synchronisation, will provide their own APIs and be extendible with other applications layered on top, plugins, etc. As we say in the telecom network world, one man's service is another man's enabler -- a mantra which is only just starting to be adopted in the handset app world. Proprietary platforms, of course, deliberately try to make it hard for people to develop those sorts of large applications (particularly the ones which provide an environment in which the user spends most of their time) because they would compete with the device brand itself for the mindshare of the user. Apple wants people to buy an iPhone and get lots of apps which add value to it. They don't want people to decide they need a certain application and then go looking for a device to run it on. But MeeGo, controlled by the LF and supporting a range of devices, should be taking the opposite approach: it should be encouraging people to build compelling and exciting environments, re-using free software, and running on a large range of platforms. I am disappointed that the LF appear to have let MeeGo compliance be captured by Intel and Nokia to make it hard to create these game-changing applications. MeeGo compliance certainly should sit on clear principles, and those principles should be that a compliant platform offers all the APIs and tools to allow creation of these sorts of new applications, as well as the openness to allow users to install them. Maybe a philosophical discussion over a Guinness next week! Graham ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
