Android has done most of such jobs via JVM. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Carsten Munk Sent: Tuesday, May 31, 2011 2:11 PM To: meego-dev Subject: [MeeGo-dev] MeeGo app model in 2012: Rethinking the MeeGo app model to be more platform agnostic
Hi, One of the disadvantages of MeeGo is that unlike Android and other OS'es, we don't provide a way for developers to provide one MeeGo compliant RPM for typical MeeGo applications+extensions that will run on all MeeGo devices, no matter if it is IA, ARM, MIPS. I'd like to spark a technical (+ compliance) discussion on if we can somehow make this reality. I'd like a world where it matters less what architecture a MeeGo device runs, or even specific optimization flags/architectures not in line with what meego.com builds when it comes to compliance, allowing more flexibility in hardware choice and hardware directions over the long term. Opinions that this isn't feasible is more than welcome :) Since we're all about fast innovation now, here's one idea to think about. With the news of Qt5 the new future application model[1] is clear. It motivates that 'While offering all of the power of native Qt using C++, the focus should shift to a model, where C++ is mainly used to implement modular backend functionality for Qt Quick.'. This will cause a development model for MeeGo API apps along lines of: * QML applications, platform agnostic, distributed as 'noarch' RPM packages. Contains QML/js files, resources, etc. * Qt Quick modules, platform agnostic, written in QML/js, distributed as 'noarch' RPM packages (think widget sets, etc) * C++ Qt Quick modules, platform specific, distributed as i586/armv7hl/mips/etc RPM packages. Contains compiled native code specific to a target processor. Typically shared objects. As you can see, we're 2/3 there to where it essentially doesn't matter what the underlying device runs, except that it provides certain APIs/runtimes for the QML apps to use. Having a MeeGo Core that we can optimize towards specific use cases and hence a wider market for MeeGo to be used in. I'd like to propose that we go to a model where we have one MeeGo API SDK with one toolchain that targets the MeeGo platform, no matter the hardware architecture. This means, take C++ Qt Quick modules and build them into a platform agnostic format (intermediate language) that is then translated by an application store or by device itself into native code, which is then run on the device. Google has already been working on a similar approach for their Native Client work, based on the LLVM intermediate format[2] and I think this is plausible to do for MeeGo too in a similar fashion in a short timeframe. They have been working on shared objects as well[3]. Now, there are some issues to be discussed and I'll list some of them: 1) Performance loss - will there be any noticable loss in application performance? Will it be mitigated by the fact the MeeGo platform + Qt stack is optimized to the target as that's where the real work goes on usually? 2) Will ARM or IA/Atom specific optimizations be lost if LLVM is used? 3) Licensing issues (GPLv3/LLVM license/etc?) 4) Security implications/signing issues/etc 5) Obfuscation and reverse engineering implications of IL being used. 6) Compliance implications 7) Hardware specific extensions And last of all: Is it plausible to have a C++ extension in LLVM intermediate language (targetted towards a fictional machine description) that links without issue into the native Qt stack across architectures? Let me hear your thoughts - I think this could be a significant platform win. BR Carsten Munk [1] http://labs.qt.nokia.com/2011/05/09/thoughts-about-qt-5/ [2] http://nativeclient.googlecode.com/svn/data/site/pnacl.pdf [3] http://www.chromium.org/nativeclient/pnacl _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
