[Development] [QtCS] QtRemoteObjects Session Summary

wim delvaux wim.delvaux at adaptiveplanet.com
Sun Jun 21 13:21:54 CEST 2015


HI guys,

Just read this mail,

I have already working code for a QtRPC based mechanism.  Support
threading, multiple parallel services, symmetric client/server (i.e server
can be client and vice versa),

Working on signals, multiple service models ( shared, group, private), auto
detection using ( in the case of TCPIP broadcast)

Sure would like you guys to step in.  Interested ?

W

On Fri, Jun 19, 2015 at 11:39 PM, Alan Alpert <416365416c at gmail.com> wrote:

> 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 ;)
> .
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20150621/2f4d255e/attachment.html>


More information about the Development mailing list