On Thu, Jun 18, 2015 at 11:48 PM, Simon Hausmann <[email protected]> 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" <[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? >> >> 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 [email protected] http://lists.qt-project.org/mailman/listinfo/development
