[Development] QtWebChannel internal protocol
mail at milianw.de
Mon Jul 7 12:31:40 CEST 2014
On Monday 07 July 2014 12:22:44 Lutz Schönemann wrote:
> On 07/04/2014 08:41 PM, Milian Wolff wrote:
> > No. I think most of this can be cleaned up nowadays. For some history see
> > this: https://codereview.qt-project.org/#/c/77481/
> > Anyhow, as I said above - patches welcome. I propose:
> > - We should get rid of the "raw" WebChannel support
> If I understand that code correctly the only difference between a raw
> WebChannel and a regular WebChannel is that the regular one gets
> initialized on client side. Meaning that the client JS library
> subscribes to signals and property updates by default. A "raw"
> WebChannel does not do that.
> If that is the only difference and there is nothing on Cpp side that is
> special for a "raw" WebChannel it should be no big deal to remove it
> from JS lib.
Yes. It should allow us quite some simplifications, at least on the client
side. But maybe there are also a few things we could then do on the server
side. At the very least, we could "merge" the QMetaObjectPublisher with the
QWebChannel[Private] where appropriate.
> > - The message structure should be flattened, i.e. "data" should go away
> > and
> > everything be put into the top-level object
> > - always use "type" to identify the type
> > - make the "id" for method callbacks a pure integer to identify which
> > callbacks to invoke on the client side
> > - more?
> Right, flatten the structure could simplify the protocol. For a reply
> messages we'd still need something like a "data" property to store the
> data returned by called method to separate meta-data from payload.
Sure, but I'd put it into a "return" property or similar.
> We used the JSON-RPC protocol in our implementation. It's widely used
> and already solved most problems occur when designing a new protocol. It
> provides everything we needed to do method calls and send signals. We
> just needed to adjust the data structure returned by "system.describe"
> function call to also describe signals, properties and enums. It is easy
> to understand and human readable (no magic numbers). Because JSON-RPC is
> developed with web services in mind it would make it easy to not just
> forward QObjects to a local/remote client but also to implement web
> services in an very easy way. The description of methods also includes
> types of arguments and return value that makes it possible to implement
> clients in a typed language (C/C++).
> What do you think about that?
No, I want to keep the protocol internal. I plan to optimize it some more in
the long-term, maybe even going full-binary.
That said, I am thinking of changing the transport API to take JSON data
structures instead of QStrings. Then, the transport could decide how to
implement stuff and you could then implement a JSON-RPC protocol transport for
the webchannel. In QtWebKit/QtWebEngine we could use Qt's binary JSON format.
I hope to find some time to implement this in the following days.
mail at milianw.de
More information about the Development