QtCS2018 RemoteObjects: Difference between revisions
Jump to navigation
Jump to search
(Added notes from the Qt Remote Objects session) |
(→Qt Remote Objects: Add category.) |
||
Line 1: | Line 1: | ||
[[Category:QtCS2018]] | |||
== Qt Remote Objects == | == Qt Remote Objects == | ||
Latest revision as of 08:08, 15 June 2018
Qt Remote Objects
This session provided an overview of the module for those unfamiliar with it and discussed what we needed to graduate it from Tech Preview to official Qt module in 5.12. Discussions on 5.12 are ongoing.
Example usage
- Projector, moderator app, embedded target
Expose QObject to another device/process
- Two fundamental pieces
- Connect Signals and propertyChanged signal to something that marshals and transmits data
- Inverse direction for Slots
- API is asymmetric, different behavior for Source (owner of interface) vs. Replica (copy)
Many extensions to this simple concept
- On connect request, serialize all properties. Latent copy.
- Handle connection loss
- Can work (with constraints) with no modifications
- QObject source, Dynamic Replica
- Use Replica Compiler (repc) to allow default properties, no errors if Source not available
- Brings in templated acquire() method
- Generates SourceAPI parameter for enableRemoting (compile-time verification)
- Node class: the object (with an address) for sharing Sources or acquiring Replicas
- Flexible backends (tcp, local, qnx currently)
- Network is peer-to-peer, but allows creation of a Registry to simplify finding the address of a Source
- Support in-process (no serialization method), so no impact to starting with APIs in one process
- Support instantiation from QML, which requires stub object due to need for default constructor
- Support RPC-like non-blocking callbacks to a single Replica
- Added proxy functionality to allow sharing objects over multiple backends
- Support QAIM
- Support sub-objects
- Support PODs, ENUMs
- Support Heartbeat
- Defaults - persist last value
Questions
- SSL backend (planned). What level of security (impacts implementation)?
- Different serialization
- Issue - doesn't make sense for QtRO to implement serialization for all types
- CBOR? Protocol Buffers? Update to QDataStream?
- Related question: Value in supporting multiple ways to packetize?
- - Non-Qt/Non QDataStream (CBOR, GPB, etc)
- Move repc from QtRO to qtbase (specifically due to moc copy)
- Python?
- Additional backends (BT, Android, file (record/playback), etc)
Questions/comments during the session
NB: please update if I missed points or got names incorrect
- Thiago commented that unlike IPC mechanisms (where an app talks to something else), Qt Remote Objects should be looked at more like a "distributed app", where state is shared between processes or devices. This currently requires QDataStream, as it is the only serialization mechanism that currently understands Qt types fully.
- Ville asked about the relation to other modules, specifically QtWebChannel. While there is overlap in how objects exposed to exposed to watching for transport out-of-process (and possible code sharing between the modules)
- QtWebChannel handles a smaller set of types than Qt Remote Objects (QAbstractItemModel, etc)
- QtWebChannel is entirely dynamic, while QtRO provides the option of using repc for stronger typing
- Someone (?) asked about what the value of repc was, and whether its functionality could be included in moc
- Good discussion, but in the end it seemed the consensus was that QtRO requires additional functions (generating QDataStream operators for PODs, Q_DECLARE_METATYPE, as well as additional attributes) that make more sense in a separate code generator.