[Qtwebengine] transport mechanisms for QWebChannel

[Hausmann Simon]

Hi,

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 ;-)

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.

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);


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?


Simon