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.
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Reply via email to