On 6/11/15, 2:47 PM, "Alan Alpert" <[email protected]> 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 _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
