[Development] [QtCS] QtRemoteObjects Session Summary

[Stottlemyer, Brett (B.S.)]

Hi Alan.  Hi Simon.

On 6/10/15, 4:23 PM, "Alan Alpert" <416365416c at gmail.com> wrote:
>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:
>>> 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.

I¹m the one who talked about QtRO (it was named Replicant at the time) at
last year¹s Contributors Summit and requested the playground.  I
definitely like the idea of making it an add-on module, but are you
suggesting it needs protocol layer adapters as a prerequisite?

The additional QML API piece would be welcome, and I¹m open to see if
there is benefit to merge/code share with QWebChannel.  I¹ve always been
resistant to try to make QtRO play nice with other languages, though.  Of
course that would be fantastic!  No argument there.  But you¹ve already
mentioned one of the difficulties - exported abstractitemmodels.  That is
a very Qt specific implementation, with support for QVariant types and
specific roles.  And concrete signals/slots.  It isn¹t a matter of simply
passing data to another language (although that is hard enough when it
comes to all the types Qt supports marshaling for already).  Even if you
could pass the data to python or java effectively, how would the receiver
be expected to display the results?

QtRO also supports ³dynamic² objects, where the method, signal and
property signatures are sent over the wire to allow a dynamic metaobject
to be created.  IIRC, even protocol buffers need to be compiled on all
sides, at least in C/C++.  Would this be a feature you would intend to
support in an adapter?

Do you have a good way of doing this without either a) duplicating a lot
of functionality interspersed throughout Qt, or b) adding a tremendous
burden to QtRO?  Again, I like the idea, I just worry about the
implementation cost.

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

I look forward to seeing what you propose.

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

This is how it is currently addressed in C++ as well, although we need to
expose the errors as signals and enhance this area.

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

Indeed.  QtRO makes it trivial to create a Replica of a Qt object in
another process or on another device.  You interact with the Replica just
as you would the original object.  It doesn¹t hide errors, but also
doesn¹t require overhead for nominal/happy-path behavior.

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

I¹m guessing you have a particular adapter in mind to start with.  What is
it?

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

Simon - I¹m curious if you think D-Bus succeeds or fails in this regard?

Regards,
Brett