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

[Oswald Buddenhagen]

On Sat, Jan 14, 2017 at 05:07:30PM +0000, Stottlemyer, Brett (B.S.) wrote:
> 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.
> 
hmm, not really what i tried to get across. i tried to point out
fundamental, architectural differences, and how the concepts relate to
each other, leaving out all the minor things that represent the current
state of the implementations.

> >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.
>
i was thinking of corba, the example i already mentioned. but i don't
know what is currently relevant in the industries we're targeting.
the task is essentially designing a meta layer (essentially, an idl,
possibly simply adopting an existing one) which can work with different
backends. the essential qt way.
of course, it may be that this task is too complex to get right, in
which case qt bindings for specific systems are a more plausible
approach. i think this is actually what we already do with activeqt.
but then the question forces itself why you had to create *yet another*
distributed object system instead of wrapping an existing one. yes, easy
type handling. see below.

> Did you mean “integrating QtRO with other RPC mechanisms”, in terms of
> layering QtRO on top of a more abstracted RPC?
>
yes, that's the first quoted paragraph above. note that it is a valid
concern independently from the second one.

> 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.
> 
well, in the worst case, the data can be simply sent along via blobs. of
course, that kind of defeats the protocol's native type support, but it
will work just fine if qt is on both ends.

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

> 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).
>
in a way, you are using dcop as the transport layer: that was kde's
qdatastream-based predecessor of dbus.

> This has been discussed in the past.
> 
indeed, google protocol buffers as a generic data serialization format
have been previously proposed here, but i don't remember the context.

> I’m not against the idea, I just don’t think it should be plumbed into
> QtRO (which it seems like you agree with).
> 
yeah. it would require describing all data types in an idl, and
providing primitives for each supported backend protocol (starting with
qdatastream ... in each existing version).

> BTW, Ossi, would which of the build systems fixes you mentioned would
> help with the qmake loop on windows CI is seeing?  ;)
> 
i don't remember. i'd have to squeeze a full review of your build system
into my todo list.