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

[Stottlemyer, Brett (B.S.)]

On 12 January 2017 at 08:39, Lars Knoll wrote:

>From the discussion so far I didn't hear too many things that speak against a TP, the code duplication with moc is one of the issues that fall into the 'flagged and need to be resolved before moving out of TP' category for me. How about the other
>points in the list above that haven't been discussed yet here?

Moving the points to below instead of above.  My opinion is (obviously) biased.

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

>* The module builds inside the Qt build system on all platforms
>    - Compilation could be disabled on some platforms, but is not allowed to break any platform we support
>* The module is CI controlled

Umm, this feels like a chicken and egg problem to me.  The Qt Company controls the CI, and it doesn’t run against play-
ground projects.  We have worked with KDAB and implemented CI on 4 platforms, targeting only Qt 5.6.2 currently.  Until
Qt’s CI is applied to it, there isn’t a clear way to evaluate build issues.  I’ve manually built against 5.8.0rc1 but
not on all platforms.  I feel like there needs to be a way to enable Qt’s CI against QtRO before deciding whether to
accept it as a TP project.  Can the Qt Company CI team help with this?  It is a playground project already hosted on
qt.io.  If not, what options are there?

>* There is a decent set of automated tests covering the main functionality and most of the API of the module
>  - The tests pass on all platforms where the module is supported
>* APIs have been reviewed, and we are reasonably satisfied with them (we've done larger changes to APIs after TPs before)
>* Architecture makes sense
>* It follows the Qt coding style and conventions
>* Implementation has been checked for sanity
>  - It's ok to have parts that are flagged as needing further work (those have to be fixed before moving from TP to supported state)

For all of the above, it seems like you need someone other than the maintainer to assess whether it meets your requirements.
I believe it does.  In terms of coding style, it meets the standards for 5.6.2.  We still need to apply the C++11 standards
for 5.7+.  Also, I’m hoping (if approved) for a recommendation on how keep the Gerrit review history and align with Qt branching.

Regards,
Brett