[Development] QtWebChannel internal protocol

Lutz Schönemann lutz.schoenemann at basyskom.com
Mon Jul 7 12:22:44 CEST 2014


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

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?

Regards,
Lutz

>
> Bye
>
>
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20140707/c523e619/attachment.html>


More information about the Development mailing list