An old/new approach to QtWebKit Hybrid

In a previous blog post, we were talking about the new direction we're taking with WebKit2, and a few people were concerned about the future of hybrid application development. Re-iterating the issues we were facing (see Ademar's comment in the above blog), it's extremely costly to maintain a deep C++ API like the one we provided for QtWebKit on top a fast-moving project like WebKit. Since I'm a fan of the hybrid approach,  I was thinking about it a lot. Though I'd much rather start my blog post with "The QtWebKit bridge now works with WebKit2", that's unfortunately not feasible. The QtWebKit bridge relies too much on the internals of WebKit(1), which has the application and the web-view bound together in a single process.

What we're trying to achieve with hybrid can be divided into three categories:

1. Tweak and control the browser window and interactions. This would still be possible to some extent as we're still exposing a WebView to QML/C++.
2. Interacting with existing web sites, for example by injecting JavaScript into the frame. This is currently not exposed in WebKit2.
3. Exposing functionality and "local" data to the web view that would otherwise not be  available to the browser.

The problem I'm trying to address here is the third one. If we look at what kind of functionality we want to access from our web view, it's in most cases data or off-screen functionality. For example, using C++ for heavier computing, a custom caching technique, or accessing capabilities such as a local calendar or microphone.
This brings me back to the way this had been achieved in the past. Since one of the things web views could always do is access the network via http, creating a small local HTTP server that exposes local functionality would give us the same value, without tying us to a particular implementation detail in WebKit, such as the QtWebKit bridge.

So what am I selling?

The idea is to use a headless web-server as a "channel" between the web-view and the host application. The server would listen on a port which would be accessible to the HTML page via HTTP requests, and the Qt application can respond to those requests and publish messages to that channel. This approach gives us that same data/functionality channel between the Qt application and the HTML page, without the need for custom APIs inside WebKit.
This is not a new approach. But, there have been a couple of issues with it in the past. First of all, security. Unlike the bridge, a local web server is not tied to a particular web view, which means that any web site can attempt to access your locally exposed functionality if it knows what port you use for your web server.
Second, integrating a full-blown Apache web-server or even lighttpd adds a lot of complexity to the equation, and buys us very little, as we don't necessarily need to support PHP, CGI, serving files with different mime-types, or a scalable process model. This becomes even more apparent when compared to the ease of use of the QtWebKit bridge, which really makes writing a standalone Qt application with a web view easier.

Introducing Qt Web Channel

So I decided to try and come up with the smallest possible implementation of a web server that would give us two things - a web server that is only accessible to certain web-views, and tight integration with the host Qt application, without changing anything in the web view internals.  A key guideline to this implementation was to not try to solve any problem beyond that. The result is below. The HTML page can send requests, and we can respond to those requests from our QML or Qt-C++ container.  The web view can also subscribe to a named message channel that QML/C++ can later publish messages to.

navigator.webChannel.exec("doSomething", function(response) {
//    do something with the response.
});

WebChannel {
        onExecute: {
            if (requestData == "doSomething")
                response.send("OK");
        }
}

WebView {
        url: "index.html?webChannelBaseUrl=" + webChannel.baseUrl;
}