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

[Stottlemyer, Brett (B.S.)]

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


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

To clarify, I simply meant that you described c++ -> idl, while the normal
process for QtRO is idl -> c++.

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

This is a bit dramatic, isn’t it?  Unless I misinterpret, you are not
suggesting the generated code change, just the process for generating it.
As such, it would seem that any change would be a drop-in replacement, so
I don’t see any criticality to the timing, especially for a TP module.

It also seems like your main objection is the use of moc, which is (as
I’ve already said) an edge case.  If this is the key sticking point, I
can drop support for converting QObjects to .rep files and remove moc
from the repo.

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

Apparently Tuukka does, since he’s suggesting holding off until 5.10...

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

Looking again now, I believe you are talking about Qt Service Framework.  It
does look familiar, so I probably looked at it and discarded it as solving a
separate problem, then forgotten I’d looked.

Top hits on google are

https://blog.qt.io/blog/2009/05/26/qt-service-framework/
https://doc-snapshots.qt.io/qt-mobility/service-frameworks.html

And
https://wiki.qt.io/Service_Framework_API


It provides platform specific implementations of services/daemons with a
common Qt API.  “Once the service has been identified the framework starts
the service and returns a pointer to it.”  This isn’t the use-case I’m
trying to solve.  It doesn’t work between platforms (like QtRO does with
the tcp/ip backend), doesn’t support Q_PROPERTY, doesn’t support default
values, and assumes services can be started from any user code.  It is RPC,
not a distributed object system.  I don’t consider it “prior art”, except
at a "rectangular device with rounded corners" kind of level.

>afaict, you just described *precisely* what qdbuscpp2xml and
>qdbusxml2cpp do, except that you decided to put both tools into one
>executable.

Right, I DO consider the dbus code to be prior art, in that is solves a
very similar problem, so I leveraged the pieces that I could.

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

Is it reasonable to assert that all of the above should either be needed for
both QtRO and QtDbus or neither?  If so, I’ll drop the moc support from QtRO
and re-add it once the above is done for qtdbus. 

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

See above.

>just some food for thought. ;)

Appreciated.  With removal of moc, can we proceed as a Tech Preview in 5.9?

Regards,
Brett