[Qtwebengine] transport mechanisms for QWebChannel

[Milian Wolff]

On Wednesday 05 February 2014 17:15:56 Hausmann Simon wrote:
> Hi,

Hey Simon!

> I've been thinking about whole situation with pluggable transport channels
> for QWebChannel again, and I have an suggestion: Let's get rid of
> QWebChannel ;-)

I'm all ears.

> 1) I think if somebody wants to send plain messages back and forth between
> QML and web content using web sockets, then Qt's WebSocket QML API should
> be designed in a way that makes this trivial and easy:
> 
> WebSocketServer {
>     id: webSocket
>     onNewConnectionRequest: {
>         var connection = request.accept()
>         connection.onMessage = function() { print("hey"); }
>     }
> }
> 
> and then maybe the server object has a serverUrl property that can be passed
> to web content.  There's a design challenge there, but fundamentally I
> think it belongs there.
> 
> 2) As you can see in the recent threads on chromium-dev, the concept of
> sending messages between web content and an embedded web view in native
> code is also an increasingly interesting use-case, and native APIs are
> getting support for it. And therefore the postMessage approach we've had in
> the WebKit2 WebView is great and it would be lovely to have something
> similar in the WebEngineView. We should advocate it and tell people to use
> it if they can.

I completely agree with these two points. The more I refactored the current 
QWebChannel code, the less I feel it makes "sense". If you want to use 
websockets, one would use QtWebSockets now. For direct IPC, use the 
WebView.experimental API. So the "simple" message passing nature of the 
webchannel is simply obsolete by now. Currently it just gives a nice 
abstracted API which can be used by both WebSockets and WebView IPC 
transparently.

> 3) Maybe I'd like to expose entire objects to web content, and for that
> perhaps we should have something like this:
> 
> WebObjectBridge {
>     id: bridge
> 
>     /* in implementation:
>     property list<QtObject> bridgedObjects;
>     default property alias bridgedChildren: bridgedObjects; // work around
> grammar limitation */
> }
> 
> Then I can write:
> 
> WebObjectBridge {
>     id: bridge
> 
>     QtObject {
>         id: firstExposedObject
>     }
>     QtObject {
>         id: anotherObject
>     }
> }
> 
> as well as
> 
>     bridge.bridgedObjects.append(myDynamicObject);

As well as

WebObjectBridge {
  bridgedObjects: [foo, bar, baz]
}

right? Assuming foo, bar and baz are defined somewhere else?

> Now the next question is: How do we connect the WebObjectBridge with web
> content?  This is where I would like to be able to just write:
> 
> WebObjectBridge {
>     id: bridge
>     ...
>     connections: [ webView1, webView2, ... ]
> }
> 
> This would use a webView built-in fast and secure transport mechanism. At
> the same time maybe I'd also like to connect it to a web socket transport:
> 
> WebSocketServer {
>     id: wss
>     onNewConnectionRequest: {
>         var connection = request.accept();
>         bridge.connections.append(connection);
>     }
> }
> 
> WebObjectBridge {
>     id: bridge
> }
> 
> The ability of the Qml engine to deal with interfaces might be sufficient to
> allow for this to work, i.e. that WebEngineView's C++ implementation also
> implements the corresponding Qt C++ interface and so would the web socket,
> without having an actual dependency to the WebObjectBridge implementation.
> 
> 
> What do you think?

I like it. And its naturally following out of the recent refactoring to allow 
a pluggable transport mechanism imo [1].

Note that this actually does not require much changes, when you replace 
WebObjectBridge with WebChannel it mostly works even now. Whats missing is the 
removal of the "raw message passing" API and pushing the transport interface 
into QtWebKit, QtWebSockets and QtWebEngine modules.

So generally, I'd say we continue to integrate the existing patch [1]. I'll 
now experiment with moving the transport interface to another module and see 
how it works. Removing the raw API later on and potentially renaming the 
WebChannel can follow.

[1]: https://codereview.qt-project.org/#change,75597

Bye
-- 
Milian Wolff | milian.wolff at kdab.com | Software Engineer
KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-independent software solutions