[Development] [QtCS] QtRemoteObjects Session Summary

[Simon Hausmann]

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

I don't think D-Bus succeeds in this regard. At least I can make my Linux 
system dysfunctional rather easily by killing off certain D-Bus services. Not 
so much because of the way D-Bus is designed but rather due to the way
the bindings are designed.

That said, I do acknowledge that a different degree of stability exists across 
process boundaries on the same machine, as opposed to networking across 
machine boundaries.


Simon