[Development] new "debugsupport" module and API
ulf.hermann at digia.com
Tue May 13 19:06:37 CEST 2014
>> Is anyone opposed to keeping this in a separate qtdebugsupport.git
>> repository, then?
> With what compatibility promises regarding code and protocol?
I would promise source and binary compatibility and backwards as well as
forward compatibility of the protocol. At the same time I would publicly
state that we'll consider replacing the whole affair with TCF or
something similar in Qt6 and deprecating the the debugsupport module then.
We in fact already have to maintain protocol compatibility so that older
and newer tools can debug different versions of Qt. We can as well make
that explicit: The protocol format is not going to change in Qt5
anymore. In order for qtdeclarative to depend on qtdebugsupport we need
it as an essential module which has to provide source and binary
compatibility. (Alternately we could restart the discussion about
submodules, but I'll only do that as last resort ...)
At the same time I know that this suffers from a serious case of NIH and
I would like to drop it at some point. However, we should really not
further complicate it. Retrofitting TCF into the current architecture
would be a major mess. With my refactoring I tried to keep the changes
to existing plugins minimal while reducing code duplication. That of
course retains bad architectural decisions of the past which are
incompatible with any state of the art debugging framework. The most
important incompatibility revolves around the need for proper
asynchronous messaging: The protocol should track messages from client
and server and associate them with each other as "commands" and
"results", so that you can send multiple commands in a row without
waiting for replies in between. The V4 debug service does that on its
own, but it should really be done by the server for all services. A good
architecture that supports this kind of interaction looks different than
one that doesn't. In addition to that a good architecture that does that
on a client which sends commands and receives results (and possibly
asynchronous events) looks different than an architecture for a mostly
reactive server. That means, once we do it properly, there won't be much
of a point in keeping server and client in the same library anymore.
I propose to clean it up a little now and redo it from scratch in Qt6.
More information about the Development