TCF/Meetings/Dec 4 2007 TCF-ECF Sync-up and Integration

Meeting Title:	TCF / ECF Sync-up and Integration Meeting
Date & Time:	Tuesday Dec 4, 2007 at 1700 UTC / 1200 Eastern / 9am PST
Dial-in:	International +44 (0)1452 567588 / Freephone +1 (866) 6161738 / UK 08712460713 / Passcode: 0587322148 #

Attendees

• Composent - Scott Lewis
• Wind River - Martin Oberhuber, Felix Burton

This is an Open call, so anyone is invited to join. Please add yourself on the attendee list and add any agenda meetings you would like to discuss

Agenda

• Clarify scope of TCF compared to scope of ECF
  • TCF is an incubating extendable protocol for communication with embedded devices, which allows value-add services to be added transparently into the communication link. Bindings may exist to a variety of languages and environments (plain C, plain Java, Eclipse). Currently, the plain Java binding is usable from Eclipse, but an ECF-based Eclipse specific binding can be added.
  • ECF provides generic APIs and mechanisms for communication from the Eclipse / Java environment, even if actual providers are written in other languages (e.g. Skype / C++).
  • What do we think about the "vertical" versus "horizontal" description of TCF compared to ECF?
  • What do we think about the name (TCF), is the term "framework" in it too confusing? Are there alternatives?
  • Is the description on DSDP/TM/TCF FAQ sufficient to clarify the scope of TCF, especially compared to ECF? Will users/extenders understand the differences?
• How to move forward:
  • One Eclipse binding for TCF should be via ECF, but a plain Java binding should be retained for plain Java environments to use TCF. The ECF binding would allow any ECF/Equinox client to use TCF for datashare (channels) and fileshare.
  • Moving forward, according to bug 210751 comment 22, a bridge should be written to turn TCF into an ECF provider for datashare (channels) and fileshare. Adding an adapter for directory retrieval to the ECF fileshare APIs could be considered.
  • TCF will live under the DSDP-TM project, including the TCF-ECF bridge (which will have a dependency to ECF obviously). Through the work on TCF, it may be possible that enhancements to ECF are contributed via patches (e.g. ECF fileshare directory retrieval).
• Clarify overlaps between TCF and ECF
  • Some core functionality exists in both TCF and ECF. Is there something (implementation, concepts) in ECF that we should bring into TCF? What would be the benefits?
    • channels (associating message with response)
    • name spaces / addressing
  • What is the Threading Model of ECF?
    • Might as well pre-answer this question. The threading model for most ECF APIs is asynchronous. What is meant by this? In the context of datashare this is exposed via non-blocking IChannel API calls, with a listener attached to the channel upon construction. The IChannelListener interface is asynchronously called when messages to the channel are received. The provider implementation of the IChannel and IChannelListener is responsible for implementing the underlying asynchrony via appropriate mechanisms (e.g. jobs or threads, etc). The IChannelListener is documented to allow the provider to call the listener with an arbitrary thread.
  • How does ECF handle addressing for transports other than TCP/IP?
    • All addressing in ECF is via ECF IDs. ECF IDs are defined to be unique object instances within an associated Namespace. In many respects they resemble URIs, but do not require the entire URI syntax. Also, ECF's identity bundle exposes a Namespace extension point that allows other plugins to define their own Namespaces, and also define ID construction within that Namespace. With this, plugins that need to address entities (other processes, etc) using something other than tcp/ip...as well as protocols built on tcp/ip...may freely do so.
  • Filetransfer: ECF has an ECF API Refactoring#Create filetransfer plugin, remove fileshare plugin action item. How does this relate to directory retrievals?
    • This particular refactoring has been completed some time ago (ECF fileshare is deprecated). RE: directory retrievals...in order to reduce the overall size and complexity of filetransfer as much as possible, directory information/browsing/navigation was initially left out of the file transfer API. This provided some benefits, in terms of size and complexity for the Equinox P2 project. However, using adapters, the file transfer API can (and eventually will) be expanded to include directory navigation. A new directory navigation adapter API contribution would be most welcome, and not technically difficult. Further, for applications that can accept the dependencies involved, EFS already provides directory navigation (and I think TM is already using EFS). Further, an ECF provider implementation *based upon EFS and the Jobs API* has already been created, and can be used in combination with the EFS directory/filestore browsing code. Obviously, such applications have to deal with the blocking I/O aspect of EFS directly.
  • Filetransfer: See API Docs for IRetrieveFileTransferContainerAdapter in ECF. Also see here
  • Here is Bug 209774 for API changes in ECF Discovery 2.0
    • This summary bug and all associated bugs have now been committed to HEAD. See here for new API.
• Clarify rules/guidelines for when ECF interfaces should be created
  • ??
• Links: DSDP/TM/TCF FAQ