I didn't find time to have a more detailed look at the code so far, but hope to
get to it over the weekend.
But in general I think we need to put the bars for becoming a TP at the right
level. It's not a fully supported module yet, and we put it out especially to
collect feedback. So it doesn't have to be 100% at the same level as supported
modules. Here are the criteria I think we should have (and that we IMO
implicitly used in the past):
* 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)
* 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
* 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)
IMO that should cover most of the needs and demands we should have for new
modules before offering them as a TP.
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?
Cheers,
Lars
On 12 Jan 2017, at 02:19, Stottlemyer, Brett (B.S.)
<bstot...@ford.com<mailto:bstot...@ford.com>> wrote:
On 1/11/17, 11:50 AM, "Development on behalf of Oswald Buddenhagen"
<development-bounces+bstottle=ford....@qt-project.org<mailto:development-bounces+bstottle=ford....@qt-project.org>
on behalf of oswald.buddenha...@qt.io<mailto:oswald.buddenha...@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
_______________________________________________
Development mailing list
Development@qt-project.org<mailto:Development@qt-project.org>
http://lists.qt-project.org/mailman/listinfo/development
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
