| Re: [tcf-dev] tcf-1.0.1 |
|
Hi Michael, I’ glad to hear you are interested in TCF. We have started TCF for same reason – GDB is not flexible enough for our needs. > The output stops immediately after the “Hello” command… Sorry to hear that. I’m not aware of changes that could cause it. You might need to trace communications on the socket level to figure this out. > We wonder why JSON was only used to transport the command arguments and results instead for the entire message We decided to make JSON optional mostly because of concerns that some service developers might prefer other formatting for the message body (or its parts). It can be helpful, for example, in a case of a service that channels some other (legacy/ binary) protocol over a TCF connection. I agree, it is not such a great benefit, but it is kind of too late to change anyway. Regards, Eugene From: tcf-dev-bounces@xxxxxxxxxxx [mailto:tcf-dev-bounces@xxxxxxxxxxx]
On Behalf Of Michael Rentschler Hi all, me and my company is very interested in the TCF project. For our targets, based upon a self-developed 16bit processors with custom debug interface and probe, we was looking for a suited protocol to communicate with them during debugging, for flashing and configuration. Since GDB was not flexible enough for our needs we was glad to see TCF being developed. Especially the extensible service model is a great benefit for us since we plan to use the protocol for any kind of communication with the target. In a first attempt we had ported the Java Agent to C++. This agent was working fine with the old TCF Client on Indigo, but as we tried to update to Juno and TCF 1.0.1 we didn’t got the client speaking to our agent anymore. The output stops immediately after the “Hello” command was exchanged and the client remains silent:
http://i45.tinypic.com/iw7qex.png. Maybe somebody here knows what changes was made that can cause such a behavior? We are very glad with the definition of the protocol so far. A bit confusing is the combination of different protocols for the transport of messages. We wonder why JSON was only used to transport the command arguments and results instead for the entire message, abandoning the use of a special data stream based upon transmission control characters? We see the protocol is very lightweight this way, but since almost any service depends on JSON we can’t see such a great benefit there. Instead, e. g. accessing an agent through a WebSocket from a Browser running _javascript_ would need some additional translation. Best regards, Michael Dipl.-Inform. Michael Rentschler Embedded S/W Engineer SMSC Europe GmbH www.smsc.com ***************************************************** SMSC Europe GmbH Firmensitz: Bannwaldallee 48, D-76185 Karlsruhe Registergericht: Amtsgericht Mannheim HRB 111275 Geschäftsführer:
Heiko Brehm, Kris Sennesael, Dr. Christian Thiel ***************************************************** Diese E-Mail kann vertrauliche Informationen enthalten. Sie darf Nicht durch andere als die ursprünglich genannten Adressaten genutzt, kopiert oder weitergeleitet werden. This e-mail may contain confidential information and should not be used, copied or disclosed by anyone who is not the original intended recipient. This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. |
