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

[Stottlemyer, Brett (B.S.)]

On 1/13/17, 10:09 AM, "Development on behalf of Oswald Buddenhagen" <development-bounces+bstottle=ford.com at qt-project.org on behalf of oswald.buddenhagen at qt.io> wrote:



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

My interpretation was that Lars was looking for differences from a Qt user
perspective, and I think my reply was accurate from that perspective.  I
would say you are looking at it from the s/w implementation perspective,
which is absolutely valid.  And I think your description is well-stated
and accurate as well.

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

[...]

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

If you really did mean other object distributions systems, which ones are
you thinking of?  Microsoft’s Component Object Model is interesting, but
I’m really not sure how to integrate with it.  Did you mean “integrating
QtRO with other RPC mechanisms”, in terms of layering QtRO on top of a
more abstracted RPC?  If so, I have a very specific reason: type support.
Many of the types Qt natively support do not work automatically with DBus
due to its intended interplay with other languages.  Many useful types
are defined throughout the various Qt modules, and QtRO supports them
all because Qt supports them all.  It also will auto generate streaming
operators for needed structures (PODs, in QtRO).  QtRO has extensions to
support QAIM types, passing batches of calls with QVariant responses
between processes.

In order to support an agnostic wire-format that works with different
languages, I simply believe support needs to be built into Qt itself,
not a specific module.  So QtRO is specific to Qt, while the qtdbus
module only provides a subset of types automatically, but it does provide
such a wire format (and allows you to extend the set of types with
additional code).  This has been discussed in the past.  I’m not against
the idea, I just don’t think it should be plumbed into QtRO (which it
seems like you agree with).

BTW, Ossi, would which of the build systems fixes you mentioned would

help with the qmake loop on windows CI is seeing?  ;)

Regards,
Brett