[Development] [QtCS] QtRemoteObjects Session Summary

[Stottlemyer, Brett (B.S.)]

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

It¹s been the generic ³Java to C++² level adapter I¹ve been worried about.
 Thanks for clearing that up.


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

It seems you are checking off my concerns, conceptually at least.  By
talking to a specific framework, you would be limiting the scope of what
would need to be marshaled, as well as how.  You would also likely have a
known set of features that could be tested, something that is hard for
QtRO and generic QObject types.

FYI, part of what repc (a compiler for .rep interface files included in
QtRO) does is support the generation of the boilerplate code to marshal
your own types.  Since this gets compiled into both sides of the
interface, you aren¹t limited in the types you can send and receive.  The
concern has been having someone add a new type to QtRO (in user space, not
in the library) and then file a bug when it doesn¹t automatically play
nice in some other language.

So in your picture of this extension, adapter ³x² would most likely just
not support specific features of QtRO, such as QAbstractItemModel
remoting?  Or, if it did, it would be the responsibility of the author to
figure out how (or, alternatively create a specific QObject to act on the
C++ side to interact with the TBD functionality of ³x²¹s framework).  Is
this correct?  This sounds reasonable.  And while it is work, it is
bounded work.

My remaining question is how to you see this tying in to QtRO.  It is
seeming that this is pointing to a pluggable back end.  That would at
least make the adapters decoupled from the rest of QtRO (that was another
concern - ³we can¹t accept QtRO as an add-on until it supports
languages/adapters x, y, z²).  We already support this in part, with the
ability to pass in a QUrl which decides whether to use QLocalServer or
QTcpServer, and can be extended to other connection types.  While this is
start, I¹m not sure it is sufficient to handle additional frameworks.  The
types are also compiled in ATM, so can¹t be added dynamically.

Brett