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 [email protected] _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev
