On Mon, Jul 7, 2014 at 6:31 AM, Milian Wolff <[email protected]> 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 > [email protected] > http://milianw.de > _______________________________________________ > Development mailing list > [email protected] > http://lists.qt-project.org/mailman/listinfo/development >
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
