Jump to: navigation, search

Difference between revisions of "DSDP-TM Connector Meeting Salzburg 2005x11x14"

 
(Notes)
Line 19: Line 19:
 
* Peter shows slide with new scenarios for connectors.
 
* Peter shows slide with new scenarios for connectors.
 
* Felix: The most difficult thing with the TCA proposal is defining the interfaces.
 
* Felix: The most difficult thing with the TCA proposal is defining the interfaces.
 +
** Hard to think about the generic connector concept
 
** Start by defining only interfaces that TM needs for registering connectors, and defining dependencies between them.
 
** Start by defining only interfaces that TM needs for registering connectors, and defining dependencies between them.
 
** Additional interfaces to be defined by connectors themselves
 
** Additional interfaces to be defined by connectors themselves
Line 27: Line 28:
 
* With our connector chain represented by some "black boxes", we want as little intelligence as possible to reside in the individual boxes.
 
* With our connector chain represented by some "black boxes", we want as little intelligence as possible to reside in the individual boxes.
 
* Michael: Interfaces for the various protocols provided by connectors could be specified in an "action-like" manner: each action to be executed is an interface in its own right, which may be available or not
 
* Michael: Interfaces for the various protocols provided by connectors could be specified in an "action-like" manner: each action to be executed is an interface in its own right, which may be available or not
 +
* Martin: TM should only hold the meta-information for connectors (that can also be programs outside Eclipse): provided-protocol, required-protocol. Example: Wind River chain of servers (Eclipse - dfwserver - tgtsvr - target agent) is mostly not Java
 +
* Felix Burton worked on "Receptacles" 1980 -- showcase that composition and configuration of connection chains can actually work

Revision as of 13:17, 19 December 2005

Meeting Title: Meeting to continue discussion on Target Connection Adapter proposal
Date & Time: Monday November 14, 2005 at 3pm CET
Location: WR Office, Salzburg, Austria

Attendants

  • Peter Lachner, Intel
  • Martin Oberhuber, Wind River
  • Felix Burton, Wind River
  • Michael Scharf, Wind River

Notes

  • Peter shows slide with new scenarios for connectors.
  • Felix: The most difficult thing with the TCA proposal is defining the interfaces.
    • Hard to think about the generic connector concept
    • Start by defining only interfaces that TM needs for registering connectors, and defining dependencies between them.
    • Additional interfaces to be defined by connectors themselves
    • TM to provide a GUI to show basic services on a target
      • Selecting a particular entity on a target might reveal new services (with interfaces defined by the parent)
  • We need to separate the protocol from the connection (somebody might want to do a protocol without a connection, just for translating protocols).
  • Michael: Connectors are like resolvers - they resolve "I want to... with target" by providing the right connection module and protocols. There might be some preconfigured resolutions, plus some autodetected resolutions.
  • With our connector chain represented by some "black boxes", we want as little intelligence as possible to reside in the individual boxes.
  • Michael: Interfaces for the various protocols provided by connectors could be specified in an "action-like" manner: each action to be executed is an interface in its own right, which may be available or not
  • Martin: TM should only hold the meta-information for connectors (that can also be programs outside Eclipse): provided-protocol, required-protocol. Example: Wind River chain of servers (Eclipse - dfwserver - tgtsvr - target agent) is mostly not Java
  • Felix Burton worked on "Receptacles" 1980 -- showcase that composition and configuration of connection chains can actually work