Difference between revisions of "TCF/Meetings/March 12 2009 Round Table"

Revision as of 14:23, 12 March 2009

Meeting Title:	TCF Round Table Meeting
Date & Time:	Thursday Mar 12, 2009 at 1700 UTC / 1300 EST / 10am PST iCal,ATOM News Feed,HTML
Dialo-in:	International +44 (0)1452 567588 Freephone +1 (866) 6161738 / Passcode: 0587322148 #

Attendees

• See the Doodle Attendance Poll for the meeting

• Wind River - Martin Oberhuber, Brian Nettleton, Doug Gaff, Doug Schaefer, Pawel Piech, Eugene Tarassov, Felix Burton
• MontaVista - Anna Dushistova, Joe Green, Yufen Kuo
• Freescale - Ed Swarthout, Daniel Friederich
• Anyware Technologies - Gaetan Morice
• Nokia - Ken Ryall
• ST-Ericsson - Henrik Wallinder
• Eldorado/TmL - Fabio Fantato

Agenda/Notes

Feel free to edit, but not during the meeting

• See the original invitation

How is TCF being used today?

• Brian, Windriver - using TCF for a remote test product (customer specific at this time)
• Joe, Montavista - not currently using TCF, but interested in standardizing on TCF for target communications
• Gaetan, Anyware - using their own (branched) implementation in a product for target communications - some patches on bugzilla
  • Moved in a slightly different direction since, because there is no agent on the target - need to merge proprietarty protocol
  • TCF not extendable enough at the moment for proprietary extensions
  • Moving in the right direction with integration of patches
  • Looking at OSGi to manage target access, want a standalone client as an OSGi bundle
• Daniel, Freescale - creating an agent on the host (in C++) - have their own C++ TCF library
  • Might be a candidate for contributing eventually, but not his to decide
• Ed, Freescale - (a different group) - using TCF agent as-is on a PPC card for transaction services, have a simple C wrapper on the client
  • Using standalone client as example with a simple C wrapper around, candidate for contribution
• Fabio, Eldorado / TmL project - using TCF agent for accessing linux system's /proc information, also working on Kernel access (will be in next TmL release)
• Henrik, ST-Ericsson - early phase, want a secure encrypted transport for handling logging on mobile phones (proof of concept for now);
  • initially a bridge: agent on the PC, linking to proprietary libs, end goal porting agent to ARM; performance is top important (because of huge amount of logging data)
  • Regarding contribution, not sure about legal situation, but can contribute bugzilla's (encryption for instance)
  • Wanted a headless lib initially, removed the Eclipse dependency, running plain Java
• Ken, Nokia - Devtools group, but there are several other groups looking at TCF as well
  • Working on debugging tools; TCF agents for native windows debugging and symbian debugging on the device; agent for symbol reading DWARF files (not based on prototype agent's code) - Felix wants to align on interfaces for symbol reading
  • Symbian agent won't run on the device initially (start as a bridge), may move to the device eventually
  • Using core protocol and parts of the agent at the moment -- their agent is C++, so removed stuff of the reference agent

Discussion

• Gaetan: Biggest problem is missing possibility to use protocol other than TCP/IP, e.g. serial; contribution is there but not (yet) accepted; but understands that it is a hard problem
  • Felix: Design is that it should be possible to add other channels - what's missing is somebody taking the time to implement (serial, udp, etc)
  • Today, most people build bridges; When Henrik moves TCF to the phone, would they use TCP? - Not yet sure, might use UDP
  • Wind River interested in other protocols, but no time yet

• Brian had trouble getting information what the plan or schedule is
  • When is a release, when is a good time to pick up a stable version, ...?
  • Martin: blackbox adoption (using unchanged downloads) vs. whitebox adoption (using, changing, exploring technology in source code)
    • Ken: More interested in whitebox - picking up technology - hasn't had problems with HEAD so far
    • Anna: MV would be interested in more communications like planning
  • Fabio: Dependency of TCF -> TM;
  • Ed: Would like a plan of additional activities: what major components does everybody work on, what's going on?
    • Martin: Bugzilla is the preferred means for discussion

• Martin: Disjoint communities at Power.org and Eclipse - how to bring them closer together?
  • Felix: Power.org discussions result in proposals on Eclipse.org for further discussion
  • No forked standardization at power.org, will be populated as a bugzilla entry on Eclipse

• Martin: maturity status information about the protocol: what's frozen vs. what's work in progress?
  • Compatibility is an issue, always try to keep the protocol compatible; doc should say what parts of the protocol are frozen
  • AI Felix add versioning information to the documents; only make backward compatible changes after a given freeze

• Newcomers - Henrik/Peter: really liked the TCF Specification document, would have appreciated more "Getting Started" stuff
  • Would like more comments in the source code
  • Martin: encourage to file bugs for missing comments, and/or contribute patches with comments
  • Felix: It's easily possible to become a committer on TCF

Release / Plans

• Making a release clarifies status, but may also hinder innovation
  • Attendees do not have any concrete need for a release, seems mostly whitebox adoption.

Summary

• In general, it looks like everybody is happy with how the project works
  • Martin clarified communication channels and encouraged filing bugzilla's and sending to the mailing list.

• Question: Announcement about Eclipse Pulsar (Platform for Mobile), using TCF?
  • AI Henrik Send question on the mailing list, Felix to look at it

Action Items

• Martin to schedule a round-table call
• Felix to add versioning information into TCF Specification Document
• Fabio to pick up TCF->TM dependency issue on the mailing list
• Henrik to mention Eclipse Pulsar on the mailing list and ask whether they are using TCF

Next Meeting

• We didn't see a need to schedule another meeting, will discuss on offline media (mailing list).