[Development] QtRemoteObjects (was Replicant)

[Simon Hausmann]

On Tuesday 21. October 2014 12.56.41 Stottlemyer, Brett wrote:
> On Tuesday, October 21, 2014 8:19 AM Simon Hausmann wrote:
> > The QTime is literally the result of string copy&paste from the token in
> > the header file into the moc generated C++ code. There's no type lookup,
> > resolution or analysis involved :)
> 
> But that's the point, isn't it?  The type itself needs to be sufficient for
> generating the protocol buffer.  MOC is relying on the fact the Qt knows
> how to copy objects of type QTime, and serialize them.  The code I pasted
> doesn't know what QTime is, but it is described in the QTime code generated
> when MOC runs on the QTime header.  It relies on introspection being
> available, and generates the code necessary for introspection as it runs
> against the Qt codebase.
> 
> Unless you expect the end user to manually write the protocol buffer, the
> exact same process of breaking down objects is needed for remote objects. 
> How else can I automatically generate a protocol buffer for QTime (or any
> arbitrarily complex QObject)?  The objects need to be self-describing,
> which is what MOC gives us.
> 
> Again, I like the idea of remote objects working outside of Qt.  Yes,
> protocol buffers are self-describing, but that is because there is a
> template.  You haven't solved the problem, you've just moved it.  You still
> need to generate the template.  Something needs to know how to
> serialize/marshal a QTime when it sees one.  And the repc compiler is the
> same as MOC in that sense.  It just grabbed the string "QTime".

Right, and it relies on the existing serialization code that is spread 
throughout Qt to serialize various objects, the QDataStream operators. Those 
are great for many use-cases, especially ones where everyone is speaking Qt 
and everyone is using the same Qt version. This is what you're building on and 
supporting with QtRemoteObjects and that's fine (it works well :)

On the other hand I think it is critical for Qt's success to also support use-
cases that leave our little universe (of Qt). And that means either building 
something yourself and convincing others to adopt it or adopt a 
technology/approach that already has existing mind share. For distributed 
objects architectures I do like the idea of supporting wire formats that have 
existing mind share and I also do think it is very important to make the 
programmers aware of the distribution.

Remote procedure calls work 99% of the time and it is very tempting to hide 
the 1% from the developer, especially since in local development environments 
the network for example is always reliable. We can just throw an exception in 
the unlikely event of a transport layer failure or the remote process 
crashing. But it is this very paradigm that a local proxy object pretends to 
be as reliable as a real local object that - in my experience - creates 
unreliable systems in the long run.  In my opinion a well designed system 
makes the programmer rather aware that remote calls can fail and that it does 
require dealing with. And that there's of course a latency involved in method 
calls.

This is clearly something where philosophies and opinions differ, so a perfect 
subject for a healthy debate of what we should focus on in Qt, as we try to to 
make software development easier.


Simon