[Development] Switch Qt Remote Objects to a Tech Preview for Qt 5.9

[Oswald Buddenhagen]

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).