Qt wiki will be updated on October 12th 2023 starting at 11:30 AM (EEST) and the maintenance will last around 2-3 hours. During the maintenance the site will be unavailable.

QtCS2018 RemoteObjects

From Qt Wiki
Revision as of 11:29, 14 June 2018 by Brett Stottlemyer (talk | contribs) (Added notes from the Qt Remote Objects session)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

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.