Qt-contributors-summit-2014-Qs2014Replicant: Difference between revisions
Jump to navigation
Jump to search
AutoSpider (talk | contribs) (Add "cleanup" tag) |
AutoSpider (talk | contribs) (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 | ||
* 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 | * 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 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