[Qtwebengine] transport mechanisms for QWebChannel

Simon Hausmann simon.hausmann at digia.com
Thu Feb 6 13:22:16 CET 2014


On Thursday 6. February 2014 13.18.41 Milian Wolff wrote:
> 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.

Yep, that's the key insight.

> > 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?

Oh yeah.
 
> > 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.

Yup, largely a renaming exercise.
 
> 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

Okay, then I'll review that and we proceed from there.


Simon



More information about the QtWebEngine mailing list