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