On Wed, Jun 10, 2015 at 7:21 PM, Stottlemyer, Brett (B.S.) <[email protected]> wrote: > Hi Alan. Hi Simon. > > On 6/10/15, 4:23 PM, "Alan Alpert" <[email protected]> wrote: >>On Wed, Jun 10, 2015 at 6:52 AM, Simon Hausmann >><[email protected]> 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?
That was the impression I got from the session. Really it's just that the developers want it ready before submitting it as an add-on module, and supporting a second usecase (like QWebChannel) is a strong sign of that. It sounded like QWebChannel needed the protocol adapters before they could jump in. There's a strong argument for making it an add-on module if we have three separate use-cases served (Ford, BlackBerry, QWebChannel). That demonstrates at least some level of value beyond a specific use-case. > 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? 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. > QtRO also supports ³dynamic² objects, where the method, signal and > property signatures are sent over the wire to allow a dynamic metaobject > to be created. IIRC, even protocol buffers need to be compiled on all > sides, at least in C/C++. Would this be a feature you would intend to > support in an adapter? > > Do you have a good way of doing this without either a) duplicating a lot > of functionality interspersed throughout Qt, or b) adding a tremendous > burden to QtRO? Again, I like the idea, I just worry about the > implementation cost. 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. >>>> The idea with protocol adapters is that currently it only sends >>>> QDataStream output over the wire. I want to send more accessible >>>> JSON-RPC (like) data over the wire for working with node, and Attila >>>> had a demo of getting object data from Meteor (although that was >>>> custom hacked for demo purposes). Protocol adapters will allow you to >>>> serialize it in these other forms, and that is the mechanism by which >>>> we gain compatibility with other languages/frameworks without them >>>> needing explicit QRO support - We'll talk their language if there >>>> exists compatible semantics. They'll probably remain separate from the >>>> transport adapters, but we'll see how the implementation develops. >>>> I'll start looking into the implementation this month. > > I look forward to seeing what you propose. > >>> 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. > >>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. > >>> The other aspect that I think is crucial in a distributed system is >>> compatibility. This is why systems like thrift and protocol buffers >>>exist: >>> They provide type safety (!) and make it really easy to maintain wire >>> compatibility. JSON is also "okay" with this, but it has the huge >>>disadvantage >>> that usually json formats are "untyped". >>> >> >>Anything you think our transport and protocol layer adapters is >>missing in this respect? Even if we first have to write a protocol >>layer adapter for each piece of compatibility we want, I imagine we >>could eventually hit upon a suitably general (yet performant) protocol >>adapter which can become standard. > > I¹m guessing you have a particular adapter in mind to start with. What is > it? I have a JSON based system at work that I need to support, but it might not be something I can share. I intend to look into meteor.js, it sounds like it might be very similar to my BlackBerry needs and serve better as a public example. -- Alan Alpert _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
