Remote Command Success

I have now instrumented the MainServer and BridgeServer to accept input text lines from the terminal and send them to the remote node! That turned out to be just a few more lines of code, once the basic input capability has already been added to TikiTerm.

Here is a screenshot showing the effects of typing the "trefoil" and "help" commands in the AUXIO BridgeServer window that connects to a remote node via WiFi. I also streamed a file to the serial port via UwTerminal, and the file appears in the UART bridge window as expected.

Oh, and we can also type commands to the remote node in the UART and MAIN server windows as well (not shown in this screen cap).

What next? There are a few possibilities:

• Currently, commands typed in the AUXIO window appear 3 times: (1) Once in yellow to acknowledge that the line has been entered into the terminal window. (2) Once in green to acknowledge that the line has been sent out over the TCP connection. (3) Once in blue to acknowledge that the line has been received and echoed back to AUXOUT by the remote Wi-Fi mote. This is perhaps overkill, perhaps I should get rid of one or more of these. Oh, and if I type the command in the MAIN or UART windows, (1)&(2) appear there and (3) appears in AUXIO.
  
  
• Presently, the main server console window also accepts commands, but no useful interactive user commands have been defined yet. Perhaps I should think of some?
  
  
• Start working on the server code to do useful processing of real-time data from the GPS app? There is substantial design work still to do on this first.
  
  
• There's always the need for improved failure recovery in the WiFi script. Like, if the server goes down and then comes back up, we should automatically reconnect. That might take a major redesign though.
  
  
• Also, in the server, I need to work on a clean-exit capability. Like, when you close the console window or type an "exit" command, everything should get shut down cleanly, connections closed, windows closed, etc. This does not happen currently (unless you run with an MS-DOS console window, and close it), and in fact I have problems with zombie threads sticking around & preventing the python process from exiting. Need some way to force them to DIE, the bastards. It's tough when they are busy listening for ports or input data or whatever. I guess I have to program them to wake up periodically and check a die flag, or some such. Too bad I can't just force-kill them all from the main thread. I should probably check some Python forums and see if there is any way to do that yet. Hm, maybe a system call to kill the process.
  
  
• One more little To-Do: Replace Python's newline() with a version that handles line-end characters in the way that I want. This will solve the problem where lines entered on UwTerminal to send via the serial input to the Wi-Fi board don't get displayed on the server until the next character is sent (which is happening because Python's readline(), when in universal mode, insists on waiting till the next character after the \r so it can figure out whether this is a lone \r or an \r\n sequence - even though there's really no need to do this prior to translating the \r to \n and returning the line to the caller.