Qt Devs, I know I've been silent for a while after the discussing Replicant and QQSM at the Qt Contributors Summit.
If you aren't aware, QQSM was renamed to DSM (Declarative State Machine) and has been incorporated into QML. It is already merged and will be released with Qt 5.4. The 2nd project was Replicant. As noted at QtCS, the name Replicant is already in use in software. So we have a new name: QtRemoteObjects. Not quite ahead of Dev Days, we've pushed it out to Qt's playground area. You can find it at https://qt.gitorious.org/qtplayground/qtremoteobjects. It is sparse on documentation, but that will be worked on over the coming weeks. We've made a bunch of changes since QtCS, some based on excellent suggestions from contributors, some based on internal needs. Hope you like it. The key to QtRemoteObjects, which I think differentiates it from other IPC/RPC approaches, is the idea of having a full (Qt) object in the new process. All property changes on the Source object will be reflected (with notification Signals) on the Replica object(s). Any Signals emitted from the Source will be emitted from every Replica. You can set properties on a Replica, as well as call Slots, but the implementation is such that the requests are sent to the Source, which responds to the calls. Any changes are then reflected by Signals or Property changes, as appropriate - this means that all instances (including the Source) will reflect the changes. The net result is that you can have a very complex object (talking to sensors, managing a resource, etc) in one process (or device), yet still interact with it in a Qt friendly way from another process (or device). All of the complexity of the IPC is handled internally by QtRemoteObjects. Feedback if, of course, welcome. Thanks! Brett Stottlemyer _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
