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.
1.5.0
Minor release with Eclipse Oxygen. Focus on quality, robustness, and Arm64 support. Also adds Port Forwarding/Tunnelling and WebSockets support.
For details see https://wiki.eclipse.org/TCF/NewIn15
The project leadership certifies that the APIs in this release are "Eclipse Quality".
Again, new adopters of TCF have confirmed the excellent architectural quality of the TCF debugger this year. Architectural issues are the same as in previous releases:
- The fully asynchronous nature of the TCF debugger is sometimes at odds with the synchronous nature of the Eclipse Platform / Debug model. Removing the few remaining blocking synchronous API's in Platform / Debug has been suggested as cure for this problem. See bug 423205 for background and details. A general adapter framework for translating between synchronous and asynchronous APIs has been implemented for the (synchronous) org.eclipse.remote.filesystem provider API using TCF asynchronous impementation.
- While TCF Core and Debugger are focused around a small, polished set of APIs, the Target Explorer offers a broad range of public (API) classes. This makes it hard to understand the big picture and how to adapt the Target Explorer.
TCF connections use a plaintext protocol based on JSON by default. This is by design, as TCF itself is focused on APIs and communication, independent of a secure (or not so secure) channel. Adopters concerned about security should tunnel the TCF connection through a standard secure channel (like SSH). The new WebSockets transport can also operate through standard https connections.
A TCF server that runs with root privileges will provide root access to the target by default. Using a firewall is therefore recommended, to protect access to the TCF server port.
Demand for more Documentation and Coding Exampes remains a concern. While the existing "Getting Started", "Porting Guide" and "API Docs" are very good for implementing a custom debugger on the TCF Framework, more docs and samples would be needed for using and extending the Target Explorer, or building custom TCF Python clients.
Commercial adopters confirm excellent usability of the TCF software. For plain Open Source users, some requests on the mailing list indicate confusion around end-to-end workflows. This will be addressed with more user-facing documentation (Tutorials, videos).
No EOL functionality this year.
There are plans to stop supporting Eclipse Platform 3.x in the upcoming TCF 1.6 release.
- The SSL support uses X.509 certificates.
- Data structures are transferred using JSON encoding.
- Python code has been formatted using the latest PEP8 recommendations.
The TCF Communities continue to grow as shown by requests on the mailing list.
Main interest of adopters is building their own debuggers using TCF building blocks, as well as getting commercial grade Eclipse integration for existing debuggers. In this respect, the well-designed TCF APIs are a very strong asset, along with the TCF C building blocks (agent) being released under the permissive EDL (BSD) license.
This year, interest in the TCF Python binding as well as the Target Explorer's connection management framework has also been observed on the Mailing list.
- Log in to post comments