[Development] [QtCS] QtRemoteObjects Session Summary

[Alan Alpert]

On Thu, Jun 18, 2015 at 11:48 PM, Simon Hausmann
<simon.hausmann at theqtcompany.com> wrote:
> On Thursday, June 11, 2015 02:21:22 AM Stottlemyer, Brett 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?
>>
>> 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?
>
> Very good point. Many of our concepts in Qt map well to concepts in other
> languages - for example signals/slots across threads and go channels. However
> the more complex the concept the harder it becomes to map and that perhaps
> isn't worth the effort. (this just as an observation, not in response to your
> concrete implementation of QtRO :)
>
>> >> 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.
>
> I feel error handling is something that's really getting better over time in
> programming. I really like thrift's new error handling and I admit I'm also a
> fan of go's put-the-error-in-your-face approach - controversial I admit :).
> But what this shows in my opinion is that particularly robust designs don't
> just _offer_ error handling to the developer, they really place it right in
> front of them when writing and reading code. I feel we haven't done that in
> the design of the Qt APIs, yet.
>
>> >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.
>
> And this is where I think Qt is best off providing functionality that makes it
> trivial to interact with other processes or devices under the rather likely
> assumption that they are not written in Qt.
>
> A current or future scenario these days is that you have mobile devices,
> processes on stationary computers, small computers on big industrial machines.
> The software in question may very well be written in Qt and C++, but it's also
> likely that in the same software scenario there's a "frontend" that's running
> in a web browser using JavaScript. This software may talk to a "service",
> which is likely written not in C++ but rather Haskell, Go, Java or perhaps
> NodeJS - running perhaps on some instance in Amazon's cloud. For a variety of
> reasons I suppose, including the availability of efficient green threads or
> simply due to expertise on the job market. And those services then may talk to
> "backend" services, unlikely to be written with Qt in my opinion.
>
> There's no strict need for these systems to speak exactly the same wire
> format, but it is critical for Qt to be able to easily interact with any of
> these endpoints through message passing.
>
> This is a somewhat lower goal that mapping entire objects across process
> boundaries, but I think it is an direction that would make Qt more attractive.
> I would love to see really good "native" thrift and protobuf bindings. I would
> love to see really convenient marshalling and demarshalling of C++ structures
> to and from JSON (something that's fortunately a work in progress). All to
> make it easy for Qt to fit into any heterogeneous environment.
>
> I see that this is almost orthogonal to your goals at this point, not
> necessarily in  conflict.

Yes, I'm still looking into (haven't had much time for it yet :( ) a
protocol level adapter, which allows us to convert the wire format.
Then as orthogonal work to the rest of QtRO, you can add a protocol
adapter for go/thrift/NodeJS whatever you want to connect to. Each
adapter would have to match the non-Qt wire format to avoid modifying
the other codebase, but eventually a standard might emerge that we can
all talk.

Although you were looking for a lower level marshalling and message
passing solution. I thought JSON over HTTP POST was good enough for
that already. I've been using it in my simple cases for a while. The
missing part I see is really the property style notifications, REST is
really just a pull paradigm that can't push out updates to values.
QtRO is one solution to that.

--
Alan Alpert

P.S: I have written a backend service in Qt that I deployed to AWS. I
think it works fine. But that's just me, and likely to stay just me ;)
.