[MeeGo-dev] "MeeGo" vs. "Platform" API ambiguity
andy at plausible.org
Thu Nov 11 13:27:44 PST 2010
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
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?
MTS, MeeGo Solutions, Wind River Systems
andy.ross at windriver.com
More information about the MeeGo-dev