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

[Stottlemyer, Brett (B.S.)]

On 1/10/17, 7:11 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:



>On Tue, Jan 10, 2017 at 01:42:12AM +0000, Stottlemyer, Brett (B.S.) wrote:
>> The processing of QObject code by repc to generate the .rep input file
>> format was added afterwards.  It allows existing Qt header files to be
>> used with QtRO with compile time checks.  We don’t use that feature much
>> internally, but others are.
>> 
>you mostly lost me here, because i just don't know enough about the data
>flows of the qtro build system, so it would be helpful if you outlined
>that.

Sure.  I guess to start off, I don’t consider QtRO to be a RPC mechanism.
In my mind, RPC would be akin to exposing a QObject’s slots for calling
individually.  With QtRO (which only works Qt to Qt, it isn’t currently
available to other “languages”, like ruby/python/etc.) you talk QObjects.

A Source object is added to the network, and clients (although I’m not
sure that is the right term) can then get a Replica of that object.  Any
change to the Source object (Signals emitted, or Q_Properties changed)
then get communicated to every Replica.  A Slot call is passed back to
the Source for handling, with any “side-effects” forwarded to all Replicas.

With this picture in mind, the key to getting it to work is to hook into
qt_metacall and pass the invocations between processes.  This takes custom
code, so QtRO has repc (REPlica Compiler) for this.  It reads a .rep file,
a simple text format for describing the object’s API via Signals, Slot,
Properties and Enums, and generates a Qt header file for the Source and
Replica sides.  The mkspecs then add these files for moc to process.

At some level, I see the .rep format as an extreme of a Q_OBJECT definition
in that only the “API” is defined (property, signal, slot, enum), and
everything else is private/pimpl.  Specific to QtRO, the Source may differ
from the Replica in that Q_PROPERTYs may be CONSTANT on the Source, but
still have a notify on the Replica.  The reason for this is that we want
Replica objects to have default values for properties that are valid
before the connection is established, and then pick up the “real” value
once the connection is made.

>but my naive understanding of rpc implementations is that you actually
>want to create some idl (is this what .rep is about?) from the c++, and
>in a later step compile that into stubs and skeletons. the former sounds
>like a task moc could do as a side effect, while the latter is for repc.

I see it as the opposite for QtRO.  The .rep defines the API, repc creates
the Qt headers for the types, then moc generates the code based on the
headers.

>as it happens, we actually have that in qtbase already, in form of the
>dbus tools. and as expected, qdbuscpp2xml is yet another tool that pulls
>in moc sources ...
>
>and obviously, moc itself could also be split into two tools.
>or, the moc frontend could be replaced with clang, for which code
>actually already exists, but wasn't deemed quite ready for prime time
>yet. maybe we could actually pull that off now that qdoc is switching
>to clang as well.

I'm interested to know if you think this is still relevant based on my
reply.  I’m not really sure how to answer.

>soliciting input primarily from olivier and thiago here ...

Welcomed.

>it's in the interest of the qt project to unify the offering as much as
>possible, minimizing redundant apis and implementations. the former are
>by definition before-freeze items, while the latter are as far as they
>cannot be done without impacting the api. (api being used in the
>broadest sense here, so tools are obviously also covered.)

Completely agree.  At the same time, I don’t want to miss the deadline for
feature freeze, so I’m hoping to get past that hurdle and address some of
your proposals afterwards as a tech preview.

As a playground project I think we haven’t gotten a lot of attention from
The Qt Company and I really do welcome that.  The repc tool specifically is
kind of in a weird spot.  I’m not sure there are any other tools that are
bootstrapped and aren’t in qtbase.  Should repc* not be bootstrapped?
Alternatively, should it be part of qtbase (so moc doesn’t need to be
“3rdParty”)?  Until QtRO is promoted to a Qt module, I don’t think these
questions can really be answered.

*QtRO will do type checking at compile time if an API gets generated from
repc.  You can also “share” any QObject via QtRO, but the Replica is then
dynamically generated and needs runtime checks.  The repc program includes
moc to it can generate a .rep file for any Qobject - thus supporting
compile time checks from existing Qt header files.  Oddly enough, the
generated code is then passed through moc again.  This is the “second”
use-case I mentioned.  I think it is a valid use case, but one I don’t use
much.

Hope that helps,
Brett