[Development] QtWebChannel internal protocol

[Matt Broadstone]

On Mon, Jul 7, 2014 at 6:31 AM, Milian Wolff <mail at milianw.de> wrote:

> 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.
>
>
Just a reminder that qjsonrpc (https://bitbucket.org/devonit/qjsonrpc) is
out there, and might be of use in your current situation.

Cheers,
Matt


> Bye
> --
> Milian Wolff
> mail at milianw.de
> http://milianw.de
> _______________________________________________
> 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/3c640b46/attachment.html>