[Development] [QtCS] QtRemoteObjects Session Summary

[Alan Alpert]

On Wed, Jun 10, 2015 at 6:52 AM, Simon Hausmann
<simon.hausmann at theqtcompany.com> wrote:
> On Tuesday, June 09, 2015 01:23:29 PM Alan Alpert wrote:
>> There was late-scheduled session on QtRemoteObjects at QtCS on
>> Saturday. QtRemoteObjects is a playground module for object remoting
>> of QObjects, and can be found at
>> http://code.qt.io/cgit/playground/qtremoteobjects.git/ .
>>
>> A brief overview of the existing features:
>> -Exports QObjects remotely, creates a replicant on the client side you
>> can interface with
>> -Network nodes can serve as a registry to allow lookup by name.
>> -Transport Layer Adapters
>> -Bjoern is currently working on exporting of QAbstractItemModels
>>
>> A brief overview of planned features:
>> -QML API
>> -Protocol Layer Adapters
>> -Investigate merge with QWebChannel (sounds similar, of course no-one
>> working on QWebChannel was present to confirm).
>>
>> After it is established with those features and solid quality, it
>> could be considered to promote it to an add-on module.
>>
>> The idea with protocol adapters is that currently it only sends
>> QDataStream output over the wire. I want to send more accessible
>> JSON-RPC (like) data over the wire for working with node, and Attila
>> had a demo of getting object data from Meteor (although that was
>> custom hacked for demo purposes). Protocol adapters will allow you to
>> serialize it in these other forms, and that is the mechanism by which
>> we gain compatibility with other languages/frameworks without them
>> needing explicit QRO support - We'll talk their language if there
>> exists compatible semantics. They'll probably remain separate from the
>> transport adapters, but we'll see how the implementation develops.
>> I'll start looking into the implementation this month.
>>
>> The question was raised "How is this not CORBA?". I'm not that
>> familiar with CORBA (just read the wikipedia article today), but my
>> suspicion is that we've cut out a lot of the boiler-plate by
>> leveraging existing Qt Meta-object information.
>
> I don't suspect that this is the CORBA criticism. I mean, it's a fair point
> that you often do end up with boiler plate translating type systems, but
> that's mostly a matter of good IDL bindings.
>
> No, the criticism I would have regarding CORBA or at least the way you may
> quickly end up using it is that it hides something that shouldn't be hidden:
> Failures.
>
> When working with "remote" services things _will_ go wrong. There will be
> issues with your connection, there will be issues with the remote side not
> responding (having crashed for example), there will be many such issues. You
> don't see them when developing the system, but during real world deployment
> you run into them, and then it's too late. During development you haven't
> encountered those issues, so your code that calls methods and reads/writes
> properties is written as if it works locally, because it did during your
> testing. Systems like CORBA encourage developers to write code as if the
> method calls were local, completely ignoring the nature of unreliable
> transports and services.
>
> I feel that mistake is made over and over again in many similar designs. It is
> perhaps one area where the web development is doing better. It's my (perhaps
> incorrect?) impression that web services tend to be accessed using more
> explicit code instead of using transparent method calls or property access.
> The XMLHttpRequest API is one example here, and the promises based fetch() API
> makes this even better IMHO.

This is attempted to be addressed (at least from the QML API) by
having explicit node objects. It can have error handling and state
communication (still to be designed), and fall-back mechanisms like
default values. I agree error handling shouldn't be hidden entirely,
but I would also say that it's still an area where we want to make
developer's lives easier with pre-built common-case logic.

We already have the XMLHttpRequest API for distributed systems. The
point of QRO, as I see it, is something more convenient and more
pre-made by comparison.

>
> The other aspect that I think is crucial in a distributed system is
> compatibility. This is why systems like thrift and protocol buffers exist:
> They provide type safety (!) and make it really easy to maintain wire
> compatibility. JSON is also "okay" with this, but it has the huge disadvantage
> that usually json formats are "untyped".
>

Anything you think our transport and protocol layer adapters is
missing in this respect? Even if we first have to write a protocol
layer adapter for each piece of compatibility we want, I imagine we
could eventually hit upon a suitably general (yet performant) protocol
adapter which can become standard.

> In my opinion a system that we promote to Qt developers should learn from
> these "mistakes" in the past: The API should encourage developers to write
> fault tolerant code (because distributed systems _do_ fail) and it should be
> easy to maintain wire compatibility (just like we do maintain binary
> compatibility).

I'll try to remember to add you as an API reviewer, so we can learn
from your experience with these mistakes.

--
Alan Alpert