[Development] QtRemoteObjects (was Replicant)

[Stottlemyer, Brett (B.S.)]

On Wednesday, October 22, 2014 6:17 AM Simon Hausmann wrote:
> On Tuesday 21. October 2014 12.56.41 Stottlemyer, Brett wrote:
>> 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 :)
Agreed.

> 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.
Sure.  I agree in concept.  But how are you suggesting we go about this?  

My resistance comes from several factors:
1) I think what you are proposing is what D-Bus brings to the table.  By focusing on the Qt side, I think remote objects is easier to use than D-Bus, but is also not seen as competing with it.  You risk both by making it more general.
2) What you are proposing is a massive increase in scope, which obviously takes a lot of time/resources to accomplish.  Is Digia offering to help?
3) As stated, the existing code is spread throughout all of Qt.  I assert that any new wire format support needs to be spread throughout Qt as well.  Otherwise you have a  maintenance nightmare trying to keep up with changes to all of the various types of objects. 

Unless you have a solution I'm not seeing, I think the best thing to do is try to future-proof remote objects so such a change is possible down the road.
	
>
> 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.
We are trying to capture these cases in an intuitive way.  If you have specific suggestions, please pass them along.  

As it stands now, the Replica has isInitialized() and isReplicaValid() methods (and corresponding signals) to describe the object status.  We recognize (and Alex Blasche pointed this out in his gerrit comments) that the error handling needs to be improved.  We intend to work on that.  Of course, patches/suggestions are welcome!

> 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.
I think the discussion needs to be whether Qt will accept an alternate or additional method of marshalling data types.  But I guess that is up for debate!

Brett