TCF/Meetings/March 12 2009 Round Table
|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 #|
- 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
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
- 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.
- 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
- 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
- We didn't see a need to schedule another meeting, will discuss on offline media (mailing list).