[Development] QtRemoteObjects (was Replicant)

[Simon Hausmann]

On Thursday, October 16, 2014 11:14:53 AM Stottlemyer, Brett wrote:
> 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.

I'm very fond of the idea of Qt making it very easy to talk to other 
applications living in other processes on potentially other machines 
(devices). I think if we want to address this in Qt, then we should take three 
requirements very very seriously:

1) Not everything is written in Qt. Perhaps only a GUI frontend? Or perhaps 
some services are written in Qt and others are written in a different language? 
I think the key to success is to allow for interoperability across 
language/runtime barriers.

2) The system must allow for versioning. Not all devices/services/processes 
will always be using the same "version" of the overall protocol.

3) The system should support a very convenient and robust mechanism to 
discover and connect to other processes.


Based on experience with an in-house project I would suggest to avoid a wire 
format that is tied to Qt, i.e. QDataStream. My current favorite on this are 
actually google protocol buffers, because they are rather good with versioning 
and you can get bindings for _a lot_ of languages, including JavaScript. 
QDataStream on the other hand is terrible when it comes to versioning, 
compared to the convenience other solutions offer. Another option would be 
CaptnProto or Flatbuffers, but they language support is not as wide spread as 
protocol buffers. Either way they are rather similar in concept and I think a 
good fit.

Regarding discovery it would be really nice to support bluetooth for peer to 
peer connectivity and zeroconf for regular IP based networks. We have had a 
very good experience using Zeroconf for this matter and it's easily available 
these days (including Android, iOS, Linux and even Windows)


Binding just QObjects across process boundaries is tempting in the short run, 
but I think it would put us (Qt) on an island. I'd much rather see Qt provide 
the low-level enablers to allow our users to either do their own RPC _and_ 
provide a sample implementation for convenience (that uses futures/promises).


Simon