devince with a built-in HTTP server. Later, they were willing to both
contribute and integrate most of that work into the main tree.
-@subsection serverdocsother Other Options Concidered
+@subsection serverdocsother Other Options Considered
What if a web browser is not acceptable ie: You want to write your own
front gadget in Eclipse, or KDevelop, or PerlTK, Ruby, or what ever
As a small group of developers, supporting all the platforms and
targets in the debugger will be difficult, as there are enough problem
-with the plethora of Dongles, Chips, and different target boards.
+with the plethora of Adapters, Chips, and different target boards.
Yes, the TCL interface might be suitable, but it has not received much
love or attention. Perhaps it will after you read and understand this.
Sure - a <em>man on a mission</em> can make that work. The GUI might be
libopenocd + Perl/TK, or maybe an Eclipse Plug-in.
That is a development support nightmare for reasons described
-above. We have enough support problems as it is with targets, dongles,
+above. We have enough support problems as it is with targets, adapters,
etc.
@section serverdocshttpbg HTTP Server Background
That also is transportable, regardless of the OpenOCD host
platform: Linux/X86, Linux/ARM, FreeBSD, Cygwin, MingW, or MacOSX.
-You could even port OpenOCD to an Google Android and use it as a
-bit-bang dongle JTAG serving web pages.
+You could even port OpenOCD to an Android system and use it as a
+bit-banging JTAG Adapter serving web pages.
@subsection serverdocshtmladv Advanced HTML Pages
*/
-/** @page serverhttp OpenOCD HTTP Server API
+/** @page serverhttp OpenOCD http Server API
This section needs to be expanded.