Difference between revisions of "TCF/Meetings/Dec 4 2007 TCF-ECF Sync-up and Integration"

Revision as of 11:51, 4 December 2007

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

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?
• How much of this exists in TCF already? Is there any point in keeping separate implementations such that a TCF Java binding can also run stand-alone?
  • channels (associating message with response)
  • name spaces / addressing
  • filetransfer
  • discovery
• Channels: 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.
    • May any thread call into ECF APIs, or just a specific thread? Are there any internal data structures that need to be kept thread-safe?
• Addressing: 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.
    • How would an application leverage EFS directory browsing with ECF fileshare? What would the benefit of using ECF be in that case?
  • Filetransfer: See API Docs for IRetrieveFileTransferContainerAdapter in ECF. Also see here
• Discovery:
  • How does discovery work in TCF? How much is implemented already?
  • 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.
  • Does DSDP-TM Discovery relate to this in any way?

Clarify rules/guidelines for when ECF interfaces should be created

• ??

Links

• DSDP/TM/TCF FAQ

Action Items

Next Meeting