On Wed, Jul 9, 2008 at 4:26 AM, Duane Ellis <[EMAIL PROTECTED]> wrote: > Øyvind > [ idea is basically "language.tcl' - where if you use language > foo - you have a 'foo.tcl' file] > > First: > > I think we can come up with ONE simple reply format that *ALL* host apps > can parse.
I don't see the need for *any* format. My thinking is that the API is the tcl you send in, not the return format. The return format is according to the convention in the frontend language.tcl you use. language.tcl itself should be considered part of the application, not the API. That said, many scripting languages may be happy with what Tcl returns natively. Perhaps that's the only thing that is needed. However, I don't want to make this decision on behalf of the user. He may *want* to do things differently than what I envisioned the world. It is *much* easier to write a routine that formats the output differently than to parse that output when it is in some unsuitable format and then massaging the data. + implementation is easy :-) Pass tcl in, get string back. Already implemented in all three transports. I think the tricky bit is that e.g. "mdw" has a human readable syntax and I believe we'll simply have to reimplement som of them rather than try to massage in some code that produces acceptable tcl output for e.g. "mdw". Another thing I worry about is that *all* openocd commands are available. While powerful, we can now break *programs* instead of just people. I feel the need to ponder this problem quite a bit more before I have anything that I would toss up as an API :-) -- Øyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9 XScale Cortex JTAG debugger and flash programmer _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
