TCF/Meetings/Aug 5 2008 Anyware-Tech

Meeting Title:	TCF Meeting with Gaetan from Anyware-Tech
Date & Time:	Tuesday Aug 5, 2008 at 1600 UTC / 9am PST HTML | iCal
Primary International Dial-in:	+44 (0)1452 567588
USA Freephone Dial-In:	+1 (866) 6161738
UK National Dial-In:	08712460713
Passcode:	0587322148 #

Attendees

• Wind River - Martin Oberhuber, Felix Burton
• Anyware Tech - Gaetan Morice
• Montavista - Anna Dushistova

Notes

Materials

• Slides about Anyware's implementation of TCF : Anyware_TCF.pdf
• Anyware's implementation of TCF and an application example : tcf_anyware.zip :
  • org.eclipse.tm.tcf : is the implementation of TCF
  • org.eclipse.tm.tcf.testservice : is an exemple of the addition of a new service (a fake service call Test) through extension point
  • org.eclipse.tm.tcf.testservice.ui : is an UI that uses TCF to access to the Test service
  • targetemulator : is an headless server (Eclipse application) that provide the Test service
  • In order to run the example you have to run targetemulator and org.eclipse.tm.tcf.testservice.ui. The access to the service is in the view Test Service view (you can access it through the menu : Window/Show View/Other .../TCF Service/Test Service view)

Background, What has been done

• Anyware works on the integration of an existing custom protocol similar to TCF, want to use it through TCF interfaces
• Wanted to use extension point to add new services -- refactor existing code to enable this. Anyware customer wanted Eclipse "update manager" capability to add new services.
• Wanted to integrate value-add server (for translating TCF protocol into customer protocol) into the Eclipse IDE
  • Use JSON for Marshalling
  • Use Serial Port channel and binary communication on back-end
  • Want to enable remote access to the target through TCF + value-add
• Changes to the framework:
  • Prototype sent by E-Mail does not have their custom protocol (only the "public" stuff).
  • Lot's of thing have been refactored in order to make it simpler to understand TCF, and add services and communication channels
  • TCF class in package "user" is now the only access point for users (it pushes further the concepts of the Protocol class in the original implementation)
  • TCFManager is the only class that adds Eclipse dependencies through Extension Points -- easily possible to separate that stuff out

Goals

• Gaetan: See if it's possible to integrate their stuff into mainstream TCF
• Martin: Understand what Anyware has done; Clarify requirements; See what could be adopted
• Felix: Worried that lot of work is starting from scratch again... goal to merge agenda and find a way that is not starting from scratch

Looking at PPT Docs

• Slide 4 "What we needed to modify"
  • "De-couple the notion of communication channel": message dispatching was too much coupled to communication in order to integrate their communication mechanism. Felix: Might be a point for improvement.
  • "De-couple the notion of service": Goal was the ability to add servers, providers and value-adds as extension point (Eclipse Update Manager). Felix: Idea of having value-add in Java was not thought about so far. Only Protocol was designed to intercept.
  • Delegate service creation etc. to Factories: in order to bring more flexibility in service life cycle management
  • Association between services and target are made through a type system: On 2nd thought, Gaetan thinks it is better to have the target define what services are available.
  • Unique and thread-safe access for framework users: This is the TCF class. Each access method checks if on the TCF thread already, and delegates into TCF thread if necessary with automatic synchronization for return value. Original TCF does not re-synchronize to original Thread, it is client responsibility to do all the Thread switching
• Slide 5 "What is not yet implemented"
  • Context identifier: not being used, stripped from the code. Anyware Services are totally different than the original one, not re-using any (even Run Control) -- Mechanism for keeping context was stripped. Felix: Context Identifier should not be in the core framework like Messages and Channels -- It might be aside the Core
    • Anyware Services are: Lots of Events (with Integer and Strings) very specific to the target, like Logger (Trace Service); different kinds of traces, plus ability to listen to specific traces right on the target (filter on the target in order to avoid communication); very simple download service; Memory Exploration (flash memory); only firmware on the target, no OS "One application at a time target / One command at a time protocol".
    • Felix: Understand why Context Identifier is not needed yet; but original TCF Services defined so far are meant to be very generic, for many different environments from JTAG to OS case. TCF C agent has not been tested in and OS-less target yet, but designed to be moved to OS-less target if necessary (planned to remove threads from the agent).
    • Gaetan: have no access to the firmware. Could probably have mapped Anyware services to existing ones, but not sure where that makes really sense.
• Slide 6 "What we plan to add"
  • EMF Transaction: Made a model of the Target, using EMFT to model multi-threaded access and persist

Next Steps

• Prototype was started from scratch in order to match Anyware's requirements; anything can be changed now
• Gaetan can make more detailed docs of what was done and why
• Martin, Felix, Eugene to read through existing PPT docs and ask questions: Need to find out what are the core new concepts of the new implementation

Action Items

• Gaetan to attach PPT slides (and, if possible, the prototype code) here on the Wiki
• Gaetan to make Bugzilla entries for individual changes, or requests
• Felix to meet Eugene in person when he is back from vacation (likely 2 weeks)
• Schedule a new meeting when Eugene has had a chance to meet with Felix and look at bugzilla requests