[Development] QtWebChannel internal protocol

[Milian Wolff]

On Friday 04 July 2014 15:12:31 Lutz Schönemann wrote:
> Hey,
> 
> I've looked into the internal protocol that is used by QWebChannel and I
> think the usage of some properties is is a bit inconsistent.

Yes, that can easily be the case - the protocol evolved a lot over time.

> In every message the client sends to the server it has to set the
> following properties (minimum):
> {
>    data: {
>      type: 6 // an integer specifying the message type (read / write
> property; call method; ...)
>    }
> }
> 
> As far as I understood that protocol the 'data' property holds the
> message payload and 'data.type' property holds the type of the message.

Yes, that is correct. It comes from the old pure-QML implementation of the web 
channel. Back then, we could only broadcast messages to all clients, and could 
never answer directly only a specific client. Also, there is still support for 
a non-metaobjectpublisher-webchannel, aka "raw webchannel". A feature, which I 
think should go away, as it more or less copies what you can do already using 
navigator.qt or pure WebSockets. I completely agree that the code should & 
could be cleaned up in that regard - patches welcome!

> There are also some more properties but the property that is confusing
> me the most is 'id'. If client sends a message to call a method it also
> has to contain that property:
> {
>    id: "id is of any type (number/string/array/object) and identifies
> the message itself",
>    data: {
>      type: 6
>      // additional properties needed for calling a method
>    }
> }
> 
> The ID property is used by the server just to send put it as 'id' in the
> response:
> {
>    id: "id is of any type (number/string/array/object) and identifies
> the message itself",
>    response: true,
>    data: {
>      // data returned by method
>    }
> }
> 
> Now, if the server sends any message to the client (property update /
> signal / ...) it uses the 'id' property not to identify the message but
> to set the message type. Here an example of a message that could be the
> result of a signal:
> {
>    id: 1,
>    data: {
>      "object": "myObject",
>      "signal": "mySignal",
>      "args": [ "arguments", "sent", "by", "signal" ]
>    }
> }
> That makes processing messages from server more complex because the the
> client has to handle the 'id' property in different ways regarding if it
> is a response or not.https://codereview.qt-project.org/#/c/81523/13//ALL
> 
> So is there a reason why you are not using the 'data.type' property in
> every case to set the message type? Maybe it should be moved from
> 'data.type' to 'type' then because for method calls it would be bad to
> change the returned data.

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

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4773 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/development/attachments/20140704/d7542cb3/attachment.bin>