[Development] new "debugsupport" module and API

[Ulf Hermann]

> 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

TCF has different messaging semantics. In particular it has message 
types (Request, Response, Event) and rules on the order in which those 
have to occur. All the plugins would have to play by those rules and the 
server and client would have to expose a slightly different interface.

Also, TCF is way more complex than what we currently have and mandates 
various things we don't actually need, e.g. a locator service. It also 
proposes standardized interfaces for various common services, e.g. 
RunControl, which of course are different to what we currently have. If 
we want to be compatible with other tools we'll have to implement that. 
If not, we can as well stick to our own protocol.

Another intersting possibility would be the gdb remote protocol because 
if we get the server stub right we could get "native" QML/JS debugging 
in gdb and lldb by using that. However, the protocol is very crude and 
not really meant for anything but debugging. So we'd have to somewhat 
misuse it to implement things like the QML profiler on top of it. There 
is a File I/O interface that could be used to fetch the data and the 
client can send custom packets using Python scripts, but do we really 
want that? Of course using gdb remote would also necessitate changes in 
all the plugins so that they output gdb commands and replies.

So, to conclude: Implementing the server side of TCF would be a lot of 
work and we should clearly know what we're trying to achieve before we 
do that. Implementing the gdb remote protocol would be easier and have 
an immediate use case, but if we don't want to put a whole lot of 
strange hackery into that we should restrict it to QML/JS debugging and 
not make it a general purpose facility.

 > Please create a new module. This doesn't need to be in qtbase.

Yes, I think so, too. There is no real reason to further bloat qtbase.

regards,
Ulf