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

From Qt Wiki
Jump to navigation Jump to search
No edit summary
 
No edit summary
Line 1: Line 1:
=Replicant QObject <span class="caps">RPC</span>=


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

Revision as of 14:01, 24 February 2015