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

[Oswald Buddenhagen]

On Wed, Jan 11, 2017 at 12:42:38AM +0000, Stottlemyer, Brett (B.S.) wrote:
> 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.
> 
technically speaking, it's a distributed object system (which puts it
into the same category as CORBA), but the underlying mechanism is still
rpc.

> 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.
>
yes, that makes .rep an idl format.

> >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,
>
i'm not sure how it's the opposite, when you effectively confirmed what
i speculated.

> then moc generates the code based on the headers.
> 
that's just a rather convoluted way to achieve the same, as marc noted
as well.

> 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.
> 
that seems a bit optimistic, given that we're discussing some rather
fundamental aspects of the design.

also, i don't think we've been bothering a lot about deadlines for TP
modules, so who cares.

> As a playground project I think we haven’t gotten a lot of attention
> from The Qt Company and I really do welcome that.
>
from experience, this isn't going to change. it's on you to reach out
(preferably without imposing a deadline).
it's your project, and it will be released in whatever state it is when
you deem it ready.

and if later somebody else with resources suddenly finds it interesting
but finds it to suck a lot, there will be struggling to get it into
shape, or to get rid of it again, to push for a better solution. we've
been there before.

it doesn't help that you apparently haven't even explored the prior art
within qt even though it was pointed out to you two years ago already.

> 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.
> 
there is nothing extraordinary about repc from the buildsystem
perspective.
there are some things to fix, but this is not place to discuss them.
other paragraphs are concerned with the duplication of moc.

> >>*QtRO will do type checking at compile time if an API gets generated from
> >>repc.
> 
> Maybe it is worth expanding on this a little bit.  [...]
>
afaict, you just described *precisely* what qdbuscpp2xml and
qdbusxml2cpp do, except that you decided to put both tools into one
executable.

the part that is shared with moc is the c++ parser, and as expressed in
the previous mail, the hope is to get rid of that entirely in favor of
clang.

that leaves us with extracting the relevant meta data from the AST, the
intermediate storage of the meta data (the idl), and the code generator.
this is all relatively little code, so sharing *as such* doesn't seem
too useful. however, it's quite ineffcient that the c++ parsing is done
multiple times, so a unified meta data processing pipeline appears
preferable:
- moc parses the c++ to create an idl file that contains all qt-specific
  meta data (what it should extract and how it should represent it can
  be declared in the headers it includes, so in principle it's possible
  to make it quite generic)
- alternatively, the user provides the idl file (both qtro and qtdbus
  support that already)
- the idl file is fed to various code generators
- the code generated by repc is not fed back into moc for parsing from
  scratch, but instead repc creates a modified idl which is fed directly
  into the moc code generator
  - come to think of it, qtdbus also has *precisely the same* problem
    (see qtbase/mkspecs/features/dbus*). you really managed to replicate
    it down to its warts. ;)

a concrete action point would be exploring in how far it's possible (and
actually sensible) to design a shared meta data representation (idl).
qtdbus' xml is horrible (of course it is), but it's easy to process.
repc's "proper" idl is the exact opposite ...

ah, yeah, qtsystems. have a look and report. ;)

just some food for thought. ;)