[Development] QtRemoteObjects (was Replicant)

[Simon Hausmann]

On Sunday 19. October 2014 18.45.57 Stottlemyer, Brett wrote:
[...]
> > 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.

I agree. I mean, it shouldn't be a necessity, but it should be easy to opt-in 
or be part of an "example" or common-case RPC system that's built on top of 
lower level components that allow custom RPC.

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

Ah, this may indeed be a misunderstanding. I'm not objecting against the use 
of Qt in the Qt side of such a system, especially as reference implementation. 
But the wire protocol, connection establishment and discovery shouldn't be 
tied to Qt IMHO but allow for other processes to be implemented using different 
runtimes. However it makes natural sense for libraries in Qt to maximize the 
use of Qt of course.
 
> 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?

Yes, it's possible to boost up QDataStream, come up with a schema format,
implement bindings in various languages/runtimes and try to gain mind share 
for it. Certainly a valid approach. Somebody has to do it though :)
 
> 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.

Yes, that's indeed a rather interesting idea. The qt dbus binding allow for 
something similar (generate dbus xml from a Q_OBJECT header).

The main issue I see is that protocol buffers first and foremost define the 
format of messages for serialization, while a meta object describes what you 
can do with an instance of an object. And I'm not suggesting the use of 
protobuf's socketrpc, that would be a poor match IMO.

So what would a .proto file look like for a Q_OBJECT? That's not evident to me 
yet.

However a .proto file could be written (manually) that describes the messages 
needed to allow calling into QObjects. Basically a schema for what QWebChannel 
also does.  In order to allow for custom types to be passed through, the meta-
type system would have to be extended to allow for registering mappings from 
meta-type ids to protocol buffer descriptors.


Simon