[Development] Request for a sandbox area: Replicant

[Stottlemyer, Brett (B.S.)]

Thiago wrote (in a different thread):
> I think the answer is pretty clear: because there are 10 other RPC 
> solutions and this needs to be harmonised.
> 
> And, to be honest, a Qt-only solution is not the most ideal. I think 
> we should use an RPC that is available in other toolkits.

Oswald wrote (in a different thread):
> maybe something more "task-oriented" like QtRpc would be 
> a better idea.

My first thought is "you're missing the point."  But my second thought is - that is certainly my fault.

My hope is that when someone thinks of Replicant (or whatever it ends up being called), they think of what it enables, not how it enables it.  I don't want the focus to be on the transport, I think that should be a hidden detail.

Look at QueuedConnections and everything that happens (behind the scenes) to make them work.  If you connect a Signal of one QObject to a Slot on another, but they happen to be in different threads, Qt automatically makes a QueuedConnection.  When the Signal is emitted the arguments are marshalled and put into the eventloop of the other thread.  When that eventloop reaches the Signal, the marshalled arguments are passed to the Slot in the 2nd thread.

Does that mean we should rename QObject to QThreadMarshalObject?  Certainly not.  

Replicant works the same way.  You are just dealing with QObjects in both (or all) processes.  The fact that there is IPC going on behind the scenes is something you don't have to worry about, it is handled for you.

Or look at it another way - look at RPC as "an API for remote calls".  So the task is usually to define that API and write the boilerplate code.  But now look at QObject.  What do the Q_PROPERTY, Signal and Slot elements provide?  An API.  So rather than defining a new API for RPC on top of the QObject (or without it), I'm simply automating the boilerplate code generation to make the QObject RPC-able.  Properties (and changes) are automatically propagated.  Signals are automatically propagated.  Slots are the return API, allowing the remote process to request local changes - which can then be propagated.

It is different.  Different in a (MHO) cool way.

The coolness is Qt only, yes.  So is the coolness of Signals and Slots, and QueuedConnections for that matter.