On Mon, Oct 3, 2011 at 12:01 PM, <dilip.kenchamm...@nokia.com> wrote: > Here is the whitepaper: > http://qt.nokia.com/files/pdf/whitepaper-qt-hybrid-server-driven-ui/at_download/file
Dilip -- Thanks for the response. I guess I've already read that paper almost a year ago... :-) -rw-r--r-- 1 npm npm 196168 2010-11-04 23:14 /home/npm/Download/Qt_ServerDrivenUIHybrid_Whitepaper.pdf > The critical, and missing, context here is that Qt WebKit hybrid is a way to > build native apps, not apps that run in a browser. Another way to think about > it: Qt WebKit hybrid lets you build an app-specific "web browser" that is > designed to run that particular app Indeed, that is exactly what I'm beginning to explore with Qtzibit ( http://nielsmayer.com/meego/qml/qtzibit.xhtml ). Using it to display and provide faceted browsing of QML datamodels, local data, or internet data. Thus Qtzibit and "mashup" stye browser displays can be used to augment existing means of display using QML -- best of both worlds, using QML as best-tool-for-the-job when it fits, and using HTML5 and a more DOM and CSS based approach when it works best. Since qtzibit and Exhibit are based on their own JSON-based abstract datamodels, it is quite complementary to the way QML works -- they can exchange JSON data much like a webserver/browser exchange HTML. Also, the "server" in this kind of app is "virtual" in that everything runs locally, but you might want to make calls out to other webservices, or the local "virtual" server to get local application or mobility data. With qtzibit, apps that normally run on a website run locally (although the google-map-based ones require an internet connection, the timeline, timeplot, chart, visualizations don't). These can run "standalone" and the associated JavaScript is loaded in from the local filesystem, computed in QML/JavaScript/C++ or transferred from the web or local SQL datastore. Qt/QML can be used to visualize arbitrary datamodels as JSON in QML, and in-turn, this JSON can be rendered via QtWebKit in Exhibit. In many ways, it duplicates or complements the "delegate"-based rendering of datamodels in Qt/QML, but uses Web-based layouts and rendering. Also, it makes sense for there to be a QML "glue layer" between the many Qt-Mobility interfaces that one may want to access in HTML5 via javascript. Finally, it's possible that such a QML "glue layer" architecture between Qt/QtMobility and QtWebKit could also be where the extra layers of security could be placed between the free-for-all world of JavaScript in the browser (cross-site scripting and malicious advertising) and system-level functionality for which this glue layer, plus Qt/QtMobility and QML would act as "middleware." For example, one can envision a kind of self-expiring-one-time-pad-like-crypto-token build into the QML middleware layer so as to ensure that only certain apps, can access certain data for certain amounts of time, etc. Similar technique could be used to secure access to DRM-protected media streams and data, where Qt and QML encapsulate native C++ code to perform secure network access or media decryption. -- Niels http://nielsmayer.com _______________________________________________ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
