Alternative Hybrid Application Architecture

In my recent article (Not So Easy) Hybrid Applications with Qt, WebKit and JavaScriptCore I reflected my opinion on the problems associated with the current Qt scripting APIs QtScript and WebKit Script. I’d like to depict the differences between both again:

QtScript and QtWebKit both use the same JavaScriptCore but from different code copies and by wrapping them both with completely different APIs. In the meantime, I have also crosscheck current status at Qt and Nokia’s scripting plans. There are two separate issue tracking databases, one at Nokia for Qt development in general and one at tracking the Qt WebKit port progress. Here are the 2 relevant entries:

I left my comment on the first one as I am still afraid that the Qt developers might come up with even a 3rd API. If that 3rd API is a unified API which can be used for QtSCript as well as in QWebKit scripting then it’d be fine. Given the comment I received from Kent on the first one, I hope for the best.

So far on that, but I want to focus now on the alternatives to the QWebKit based approach to building hybrid – i.e., Web enabled – applications in C++. First of all, WebKit in itself is an outstanding HTML rendering engine, both in performance and portability, both of which features I wouldn’t want to lose. That’s why I seek a solution based on WebKit, which could look like in this diagram:

The first and most important change is that whilst WebKit is still in it, it is not wrapped by Qt any more. Using the WebKit API directly, I would have access to the complete publicly available functionality in WebKit via e.g. HTMLElement and HTMLFrame classes. This would be to a great advantage. On the con side, I would lose Qt’s additional features from the wrapper classes, but I think they weren’t that many so that should be no big deal. Most of the customization would have been done using overridden event handling functions of the QWebView anyway and not via signals/slots as there aren’t many of them available (yet).

However, there are 2 big question marks associated with this architectorial picture:

  1. How can WebKit be used in a standalone way?
  2. Could I get rid of Qt completely then?

Q1 is not easily answered. If you look at the WebKit project structure you will find that it’s very much interwoven with the different ports like Safari or Chrome at the source code level. Port specific functions are partially included in the kernel and the same or more applies to the build process. WebKit is not a library that you can just consume. All ports are centrally built on WebKit’s environment and good builds are consumed by the browser vendors as a whole including the vendor specific extensions to whatever extend they want those to have public. You can get an impression here: WebKit Buildbot: Waterfall Display To make it worse, the whole WebCore engine is nearly completely undocumented in the source code. Only some public introductory documents are available in their Wiki or perhaps something more advanced on the Chromium Homepage. But nonetheless, a port should be possible, though with quite some effort, in a way to render to the underlying OS’s platform Grahics2D subsystem.

Although I am miles aways from making any achievement on this I have a better picture on the answers to question #2:

Qt’s feature rich functionality provides an experience to the C++ application developer which is at about the same level as the Java runtime library is to the Java developer. Which means: it will be hard to replace.

In the picture above I have created two possible scenarios for the replacement of certain aspects of Qt my application is making use of. It will – though not effortlessly – be possible to continue living without Qt either by consuming some functional equivalent from boost or by implementing a proprietary replacement. I have mixed feelings about boost, even though I consider it the right approach to utilize templates to be as syntactically clean as possible in C++, this excessive use of templates does not really lead to intuitively readable code which makes me reluctant and I tend, given the meta-driven approach I am implementing anyway, to replace of the Qt functionality by proprietary code making use of my meta level elements.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s