Qt-contributors-summit-2014-Qs2014Replicant
Jump to navigation
Jump to search
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