On Fri, Jan 13, 2017 at 01:58:45AM +0000, Stottlemyer, Brett (B.S.) wrote: > On 12 January 2017 at 08:39, Lars Knoll wrote: > >* The module solves a problem our users have > > - It either implements new and so far non existent functionality > > - Or it solves an existing problem in a new and better way (and is > > intended to replace the old functionality over time) > > It seems like the two potentially competing current projects are Qt Service > Framework and QtDBus. I believe QtRO is > different from both, with “better” being subjective. At the risk of being > flamed for why I prefer QtRO, I’d put it > this way: > > The Qt Service Framework deals with OS Services/daemons, and only works > inter-process, not inter-device. If I can > distinguish between a service and a Service, Service being a different class > than a program (I.e., on windows, services > run when no user is logged on). If you need a Service, the Service Framework > makes sense. This isn’t the problem > QtRO is trying to solve. > > QtDBus is more similar in intent to QtRO. QtRO is peer-to-peer, while Dbus > by default goes through a daemon. Bus is > common on Linux platforms, but has additional dependencies on other platforms > (Windows, QNX, etc). The key difference > though, is that DBus is intended to translate between languages (java, C, > python). This is a disadvantage of QtRO > in many cases, but when Qt is available for both client/server, it provides a > much richer level of communication. For > instance, QtRO supports QAIM, including selection, across processes/devices. > It supports state (current PROPERTY > values). It supports any type Qt can (or can be made to) pass in Queued > connections. Without additional code. > > My view is that QtRO complements the other two options, providing strong > benefits for the right use-cases. > for my taste, there are way too many inconclusive/irrelevant details in this description. a more layer-oriented approach would be more convincing imo:
qtdbus is a pure rpc layer. qtro is a distributed object layer which builds on top of rpc. signals and slots are exposed rpc. no idea whether you implemented property propagation on top of generic rpc or via a dedicated protocol part, but that's just an implementation detail. it would be perfectly feasible to implement qtro over qtdbus (networked dbus has been on the table for a decade; dunno if somebody ever pulled it off). qtserviceframework is a registration/management layer on top of (local) rpc. its intended use appears to be more the creation of platforms rather than applications, which might explain why it's now bitrotting. ;) it appears to me that it would be possible to build it on top of a higher-level representation like qtro, but principally it's indeed rather orthogonal. from a purely design perspective, it would seem optimal to have a QtRpc system of which QtDbus provides a concrete implementation, while QtRo would be the state extension building on top of it. this would imply multiple inheritance for an actual instance of qtro. the principal advantage of this would be a shared idl and surrouding tooling, which would reduce redundancy on the implementation side. otoh, we have the existing implementations, and in particular qtdbus really isn't at a point where it could be just redesigned. we can't drop the existing qtdbus-xml, and it would be sado-maso to make .rep an extension of that format. a more realistic appoach would be having qtdbus as an "invisible" backend implementation of the generalized qtrpc. note that qtserviceframework has some of this, which is probably why alex considered it relevant in the first place. so a concrete action point would be investigating in how for it's possible (and actually sensible) to factor out the rpc layer (including the underlying transport layer, obviously). it's not really clear to me why you're apparently discarding the idea of integrating qtro with other object distribution frameworks at the outset. the systems really aren't fundamentally different, and providing such integrations may significantly improve qtro adoption where a system is already established (or is being prescribed). _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
