Qt-contributors-summit-2014-Qs2014Replicant

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

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