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