[Development] QtRemoteObjects (was Replicant)

[Stottlemyer, Brett (B.S.)]

On Sunday, October 19, 2014 10:12 AM Simon Hausmann wrote:
> 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). 

Me too   ;-)

> I think if we want to address this in Qt, then we should take three requirements 
> very very seriously:
>

... skipping #1 for a moment

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

I agree, and I recognize this is one of many things that should be improved going forward.  Same applies to types being passed by the protocol (as opposed to the protocol itself).

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

I agree, and I'm a fan of zeroconf myself.  But it needs to be optional, as I can think of cases where it would not be desired.  So I see this as more of an extension/enhancement.

> 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.

I agree in theory (who wouldn't?), but not at all in practice.  Off the top of my head, I'm using:

QIODevice/QDatastream/Q<type>Socket/Q<type>Server for communication
QVariant for data marshaling
MOC for Properties/Signals/Slots, including object introspection
QEventLoop for event serialization, notification
+More (container classes, qpa, etc)

If the suggestion is to use/create non-Qt versions of all of the above, why use Qt at all?  Or maybe I'm misinterpreting your suggestion?  It doesn't sound like you are thinking of a wrapper, along the lines of PyQt/PySide, so I'm not sure what else you could mean.  Please clarify.

Also, your points on protocol buffers and limitations of QDataStream are more accurately issues with Qt itself, aren't they?  Should they not be addressed directly in Qt, rather than only in a playground module?

More specifically, why not incorporate protocol buffers directly into Qt's QObject/MOC?  I'm not kidding here, the thought has occurred to me several times when creating custom qt_metacall() code.  Within the MOC generated code, you have void * pointers, QVariants and static_casting to/from types relying on the auto-generated code to guarantee the necessary types.  Why not have MOC auto-generate protocol buffer templates instead?  You already need to compile the MOC output, which could compile the protocol buffer just as easily.  

Such an implementation would provide simple validation, improved type safety, and possibly a performance boost.  It would remove the artificial/arbitrary 9 argument limitation (as in QMetaMethod::invoke).  It would probably be overkill for DirectConnection, but would make sense for QueuedConnection, where you need to copy the arguments anyway.  And it would also likely simplify/standardize QVariant and QDataStream as well.  

And then extending QtRemoteObjects would be a lot more straight forward.

Brett