Qt-contributors-summit-2014-Qs2014Replicant: Difference between revisions

From Qt Wiki
Jump to navigation Jump to search
(Add "cleanup" tag)
(Simplify punctuation)
Line 15: Line 15:


* properties are not cached everywhere
* properties are not cached everywhere
* don’t want to spam the channel on every property update
* don't want to spam the channel on every property update
* only those properties that are used must be sent
* only those properties that are used must be sent
* could be written on top of dbus, but is not so far
* could be written on top of dbus, but is not so far
Line 29: Line 29:
* inconsistent state could be seen, where only setX was called?
* inconsistent state could be seen, where only setX was called?
* could be solved, with eventloop etc. pp. e.g. block updates, disable/enable
* could be solved, with eventloop etc. pp. e.g. block updates, disable/enable
* replicant can use pod data types with automatic marshalling to “solve” this (setXY?)
* replicant can use pod data types with automatic marshalling to "solve" this (setXY?)


==concern: making it qt specific==
==concern: making it qt specific==
Line 40: Line 40:
==introspection:==
==introspection:==


* it’s all QObjects!
* it's all QObjects!
* it’s not possible without the compile-time interface
* it's not possible without the compile-time interface
* also question of versioning: is this object V2 or V1?
* also question of versioning: is this object V2 or V1?
* could be done with private QObjectBuilder
* could be done with private QObjectBuilder

Revision as of 13:25, 23 August 2015

This article may require cleanup to meet the Qt Wiki's quality standards. Reason: Auto-imported from ExpressionEngine.
Please improve this article if you can. Remove the {{cleanup}} tag and add this page to Updated pages list after it's clean.

Replicant QObject RPC

Partecipants:

Notes

how to change properties from the replicant side

  • call slot, prime will handle the update and send signal
  • or just change property if it has a change signal it should work

why not dbus?

  • properties are not cached everywhere
  • don't want to spam the channel on every property update
  • only those properties that are used must be sent
  • could be written on top of dbus, but is not so far

race condition in dbus: get data, then listen to updates, with update inbetween

  • first ask for updates
  • then ask for initial values
  • should work?

inconsistency: replicant calls two setX, setY

  • inconsistent state could be seen, where only setX was called?
  • could be solved, with eventloop etc. pp. e.g. block updates, disable/enable
  • replicant can use pod data types with automatic marshalling to "solve" this (setXY?)

concern: making it qt specific

  • same problem as with QDataStream (see dcop/dcopc)
  • separate qt module with qt specifics is fine

no patches to qtcore or anything required

introspection:

  • it's all QObjects!
  • it's not possible without the compile-time interface
  • also question of versioning: is this object V2 or V1?
  • could be done with private QObjectBuilder

overhead:

  • only once a replicant is connected
  • otherwise plain QObject-like

security:

  • authorization: capability/permissions, how are they handled?
  • could be done via custom io class, maybe
  • qsslsocket only part of the solution
  • see e.g. pocket/dbus on how to do that (but clumsy)
  • alternative is a daemon (but thats not what replicant has)
  • identify client who is calling is a central question to solve

error handling:

  • not yet implemented