Hi, we currently have several implementations of the QML debug protocol used to transmit data between a debugger or profiler and the application being debugged or profiled. I'm proposing a generalized "debugsupport" module to address various issues with those. In particular:
1. Code duplication ------------------- We currently have implementations of QPacketProtocol in: - qtdeclarative/src/plugins/qmltooling/shared/ - qtdeclarative/tools/qmlprofiler - qtquick1/src/declarative/debugger - qt-creator/src/libs/qmldebug We have differently named but functionally largely identical implementations of the qml debug client and connection in: - qtdeclarative/tests/auto/qml/debugger/shared - qtdeclarative/tools/qmlprofiler - qtquick1/src/declarative/debugger - qt-creator/src/libs/qmldebug We also have 2 server implementations, in qtquick1 and qtdeclarative. The debug clients and servers share a lot of functionality regarding connection handling and notifying their plugins about various conditions. Those plugins for servers and clients can share the same base class as they all expose the same interface to the server or client. Currently we have 6 of those base classes. 2. Missing flexibility ---------------------- Currently a TCP connection is used for any kind of debugging or profiling. This is potentially wasteful and dangerous as TCP has a certain overhead and the protocol itself doesn't care about security. Providing a connection over a QLocalSocket at least as an option seems to be a good idea. The debug server is currently tied into QtQml, even though it has technically nothing to do with QML. It's a general purpose tool for interacting with an application over a defined interface. It should live in a more appropriate place so that we can use it in other contexts if the need arises. 3. Messy implementation ----------------------- Many of the client implementations are badly written, potentially leak memory, don't properly handle errors, expose too many details of the underlying connection and provide subtly different interfaces to their plugins. It's also a bad idea to specify the interface between the debug server and client in terms of an arcane binary protocol full of magic numbers and with a colorful history (e.g. the protocol version is unusable; we practically never do service advertisement; in order to extend the protocol you can only add things to the end of messages, but you can never change any existing parts; service versions are transmitted as floats). Hiding the mess behind a clean C++ interface will make it much easier to work with and enables us to eventually replace the protocol with something less crazy. The following changes create a debugsupport module with public API in qtbase: https://codereview.qt-project.org/#change,85098 https://codereview.qt-project.org/#change,85099 https://codereview.qt-project.org/#change,85100 https://codereview.qt-project.org/#change,85101 https://codereview.qt-project.org/#change,85102 https://codereview.qt-project.org/#change,85103 I also have some WIP changes for qtdeclarative to use debugsupport: https://codereview.qt-project.org/#change,84103 https://codereview.qt-project.org/#change,84527 And for QtCreator: https://codereview.qt-project.org/#change,84526 QtQuick1 will get the same treatment. -- Ulf Hermann, Software Engineer - Digia, Qt _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
