[Development] new "debugsupport" module and API

[Koehne Kai]

> -----Original Message-----
> From: André Pönitz [mailto:apoenitz at t-online.de]
> [...]
> Consolidation of various incarnations of the code might make sense,
> exporting would need a good reason.

One of the reasons for the different incarnations of the client side of the debug API
in Qt Creator & qtdeclarative is that it's not public API, and we usually try 
to avoid using private Qt API in Qt Creator. Instead, we just copied it.

An alternative to making it exported API would be putting it 
in a git submodule that Qt modules & Qt Creator use ... Anyhow, 
what's wrong with making it a proper Qt Addon instead? 
We have the infrastructure for this already.

Btw, I can easily see other IDE's (KDevelop) and tools  (GammaRay) profiting 
from this infrastructure too. Wouldn't  a unified way to inspect/talk to a running 
Qt application be helpful?

> > One thing Andre raised though was whether we should continue running
> > our own (albeit improved) proprietary protocol, or try to integrate
> > into / implement TCF:
> >
> > http://wiki.eclipse.org/TCF
> 
> My main point was not to go for TCF, but that we should not go further down
> the NIH route _before checking out existing alternatives *and* establishing
> they don't fit the purpose_.

Understood. Still, I'm wondering whether adopting (parts of) TCF buys us anything else
then using "something documented". This advantage could be e.g. marrying the
Qt services then with a stock TCF service/infrastructure, or reusing an existing 
TCF implementation internally.

There's also adb (Android Debug Bridge), though the protocol itself is AFAIK not 
properly documented (short of http://blogs.kgsoft.co.uk/2013_03_15_prg.htm, which 
starts with "Yet, the internal logics of ADB are very complex. Compounded with the lack 
of documentation, it is extremely difficult to understand how it works and how it is 
actually implemented." - not very encouraging).

Anyhow ... let's keep in mind that the current infrastructure / protocol is there and is working.
Ulf obviously wants to clean it up & extend it, but switching to an entire different protocol
with different semantics isn't exactly a free ride. Maybe it's worthwhile in the long run,
but we're not in a situation where we start from scratch, and just wonder whether we
should use an established protocol, or invent our own one.

Regards

Kai