Reviews run for a minimum of one week. The outcome of the review is decided on this date. This is the last day to make comments or ask questions about this review.
TCF 1.2 is delivered for the Eclipse Luna simultaneous release. This is a minor release with no API changes allowed. The release is focused on robustness and improved test coverage, to support commercial adoption of the TCF Debugger. In addition to that, the "TCF Terminal (Console) View" has been productized providing an Eclipse-embedded commandline on Windows, Linux and MacOS X.
The project leadership certifies that the APIs in this release are "Eclipse Quality".
Over all, the TCF Architecture has proven solid, robust, and very well maintainable. The very small amount of changes on the TCF Protocol during the 1.2 release cycle in spite of significant implementation improvements shows the great quality of the TCF Protocol APIs. Defects have been few, isolated, and mostly easy to track down thanks to componentization.
Only two noteworthy architectural issues come to mind:
- The fully asynchronous nature of the TCF debugger is sometimes at odds with the synchronous nature of the Eclipse Platform / Debug model. This sometimes leads to the Eclipipse IDE perceived as "hanging" when an asynchronous resonse isn't received. Removing the few remaining blocking synchronous API's in Platform / Debug has been suggested as cure for this problem, but so far this task has not been started yet. See bug 423205 for background and details.
- The TCF Target Explorer offers a very broad range of public (API) classes, making it hard to understand the big picture and how to adapt it. More community adoption, examples and documentation would be needed to imrove this situation. Community interest has still been sensed in adopting the Target Explorer's Common Navigator based architecture.
None known at this time. TCF connections use a plaintext protocol based on JSON by default, but can optionally be routed over SSL ports for security.
Not all TCF server code that listens on TCP/IP ports has been reviewed for potential security issues (like DDoS attacks) though. Since TCF is primarily meant as deveopment-time tooling in the lab, this is not seen as an issue. Thanks to the protocol channel abstraction, TCF can always be tunneled over alternative communication channels (such as SSH) if desired.
A TCF server that runs with root privileges will provide root access to the target by default.
Examples have slightly been updated in this release, including a "minimal footprint" example. The "Getting Started", "Porting Guide" and "API Docs" are good. Some Protocol docs and a tutorial are missing, but still some community members have succeeded in this release cycle building their own debugger on top of TCF. A talk on building a commercial-grade debugger on TCF was given at EclipseCon NA 2014, and a "Lightning Talk" was given at Embedded Linux Conference 2013 in Edinburgh.
The target explorer has been greatly improved in this release in terms of usability and workflow simplification. The new "Toolbar Control" helps getting quick access to remote systems easily from any context. Dialogs have been reviewed and improved for usability.
104 Bugs or Enhancement Requests have been closed in the TCF 1.2 release, but many issues are actually resolved by committers directly in GIT without filing a defect. The backlog is slightly increasing over time, from 70 issues in bugzilla in 1.1 last year, to currently 98 open issues. This number includes currently 35 enhancement requests.
No End of Life in the TCF 1.2 release.
There are plans to stop supporting Eclipse Platform 3.x in the upcoming TCF 1.3 release, as well as to stop supporting TCF agents older than version 0.4 and to stop Java 6 support.
- The SSL support uses X.509 certificates.
- Data structures are transferred using JSON encoding.
- The Terminal integration supports SSH
- Python code has been formatted using the latest PEP8 recommendations.
We hope that with releasing the new "TCF Terminal (Console) View" which is of general use for any Eclipse user, we can get even broader adtopion in the user community. Most interest in TCF still comes from silicon vendors. In the general public and the Linux community, LTTng and GDB remain the established standards for now, although TCF is stronger in terms of its technical architecture.