All,
Yesterday Jim made some observations about errors and error trapping in
the update command processing in jsdr. This was coming sooner or later
but, being very lazy, I wasn't going to do anything about it until
somebody complained. If it ain't broke etc. However it *is* somewhat
broke so it's time for a fix.
The problem is that the update command processor has some knowledge
about whether a command is malformed, and it makes a feeble attempt to
report that fact, but there's no way for that information actually to be
communicated back to whoever issued the command.
Another fact not yet in evidence. For various reasons, stdin and stdout
in jsdr are virginal. Everything that goes in or out, does so on a
stream that's been opened explicitly.
What I'm proposing is to modify jsdr so updates are sent to stdin, and
returns from update are sent to stdout. I should stress that this has
*minimal* consequences for current designs. Whether networked or local,
the only difference is in how jsdr is started up. It does open up a
considerable range of possibilities beyond mere error reporting,
however. For example, new commands can be constructed that return
internal information about the DSP state, and so on.
Without belaboring the details, let me add that the return feature adds
really nothing significant in the way of additional complications as far
as remoting or networking are concerned, and it's easy enough to select
on a command-by-command basis.
Comments?
73
Frank
AB2KT
