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 [email protected] http://milianw.de _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
