[Development] [QtCS] QtRemoteObjects Session Summary

Alan Alpert 416365416c at gmail.com
Thu Jun 11 20:47:36 CEST 2015


On Wed, Jun 10, 2015 at 7:21 PM, Stottlemyer, Brett (B.S.)
<bstottle at ford.com> wrote:
> 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?

That was the impression I got from the session. Really it's just that
the developers want it ready before submitting it as an add-on module,
and supporting a second usecase (like QWebChannel) is a strong sign of
that. It sounded like QWebChannel needed the protocol adapters before
they could jump in.

There's a strong argument for making it an add-on module if we have
three separate use-cases served (Ford, BlackBerry, QWebChannel). That
demonstrates at least some level of value beyond a specific use-case.

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

They have their own modules on their side. One of the sessions you
missed included a demo with Meteor.js talking to QML applications
using a somewhat similar approach. It had custom logic that mapped
Meteor's wire protocol into QObject like structures so that QML could
use it. Or at least that's how I assume it worked, given that I have a
similar case myself with a specific node.js server at work (all this
travel and 5.5.0 release and I haven't had a chance to checkout
Attila's code yet). It would *NOT* be a generic "Java to C++" level
adapter, it's specific FW (Qt) to specific FW (e.g. Meteor.js)
assuming they have QObject compatible semantics.

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

Then I'll start working on the implementation, because my idea of it
was that the cost would be low. I'll add you to the change on gerrit
when I have a draft ready.

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

I have a JSON based system at work that I need to support, but it
might not be something I can share. I intend to look into meteor.js,
it sounds like it might be very similar to my BlackBerry needs and
serve better as a public example.

--
Alan Alpert



More information about the Development mailing list