Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "TCF/Meetings/Dec 4 2007 TCF-ECF Sync-up and Integration"
(→Agenda) |
|||
| Line 21: | Line 21: | ||
* Clarify overlaps between TCF and ECF, and how to move forward | * Clarify overlaps between TCF and ECF, and how to move forward | ||
** What is the Threading Model of ECF? | ** 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 [[ECF_API_Docs#Datashare_API|datashare]] this is exposed via non-blocking [http://www.eclipse.org/ecf/org.eclipse.ecf.docs/api/org/eclipse/ecf/datashare/IChannel.html IChannel API] calls, with a [http://www.eclipse.org/ecf/org.eclipse.ecf.docs/api/org/eclipse/ecf/datashare/IChannelContainerAdapter.html#createChannel(org.eclipse.ecf.core.identity.ID,%20org.eclipse.ecf.datashare.IChannelListener,%20java.util.Map) listener attached to the channel upon construction]. The [http://www.eclipse.org/ecf/org.eclipse.ecf.docs/api/org/eclipse/ecf/datashare/IChannelListener.html 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? | ** How does ECF handle addressing for transports other than TCP/IP? | ||
| + | ***All addressing in ECF is via ECF IDs. [http://www.eclipse.org/ecf/org.eclipse.ecf.docs/api/org/eclipse/ecf/core/identity/ID.html 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? | ** Filetransfer: ECF has an [[ECF API Refactoring#Create filetransfer plugin, remove fileshare plugin]] action item. How does this relate to directory retrievals? | ||
** Filetransfer: See [http://www.eclipse.org/ecf/org.eclipse.ecf.docs/api/org/eclipse/ecf/filetransfer/IRetrieveFileTransferContainerAdapter.html API Docs for IRetrieveFileTransferContainerAdapter] in ECF | ** Filetransfer: See [http://www.eclipse.org/ecf/org.eclipse.ecf.docs/api/org/eclipse/ecf/filetransfer/IRetrieveFileTransferContainerAdapter.html API Docs for IRetrieveFileTransferContainerAdapter] in ECF | ||
Revision as of 20:35, 1 December 2007
| 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 # |
Contents
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?
- Filetransfer: See API Docs for IRetrieveFileTransferContainerAdapter in ECF
- Here is Bug 209774 for API changes in ECF Discovery 2.0
- What is the Threading Model of ECF?
- Clarify rules/guidelines for when ECF interfaces should be created
- Links: DSDP/TM/TCF FAQ