[Development] QtWebChannel internal protocol

[Milian Wolff]

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.

Bye
-- 
Milian Wolff
mail at milianw.de
http://milianw.de