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 <[email protected]> wrote: > 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 >
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
