> -----Original Message----- > From: André Pönitz [mailto:apoen...@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 _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
