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

Revision as of 20:51, 1 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

• Clarify scope of TCF compared to scope of ECF
• Clarify overlaps between TCF and ECF, and how to move forward
  • 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 [ECF_API_Docs#File_Transfer_API 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

Action Items

Next Meeting