>> 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. regards, Ulf _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
