Uniform reply behaviour of FGInputSocket::Read

[agodemar]

This PR comes from issue #63, where part of the discussion concerns the behaviour of JSBSim when used as an input server responding synchronously to an external application connected via socket.

In that discussion I refer to an example of use where a client app

• sends first a get command to JSBSim,
• JSBSim replies sending a string back to the client with the value of the asked property,
• the client then sends a set command, which succeeds
• finally the socket is closed by the client and JSBSim continues its propagation algorithm until the final time.

All commands sent as string by the example client application to JSBSim through the input socket are digested by JSBSim's FGInputSocket::Read. This function parses the string checking the validity of the command, eg.:

• get <property>
• set <property> <value>
• hold
• resume
• iterate <int>
• quit
• info
• help

and finally calls Reply that sends back through the socket a string message to the client.

In the current version of FGInputSocket::Read, for some commands like a successful set <property> JSBSim replies with an empty string followed by the prompt JSBSim> . No new line character. See FGInputSocket.cpp, line 173. The same behaviour is implemented for hold, resume, iterate, and quit.

In the present PR I've changed the reply messages in case of successful set, hold, resume, iterate, and quit prepending to the "JSBSim> " prompt a confirmation message terminated by a new line character \n. For instance:

Set successful
JSBSim>

or

Holding
JSBSim>

or

Resuming
JSBSim>

and so on.

This harmless change

• gives a uniform reply behaviour, i.e. always a one-line message terminated by a \n plus the prompt string JSBSim>
• facilitates external client applications when parsing the replies, e.g. they could read from the socket until the \n character and throw away the remaining ones.

[seanmcleod]

Given the original interactive design with the JSBSim> prompt etc. I guess there shouldn't be any issue adding success messages as part of the reply.

For automated programs I guess currently they could read the reply looking for the JSBSim> prompt string as opposed to specifically looking for a \n terminated string?

If you merge this in make sure to squash all the commits into a single commit so that some of the earlier commits that temporarily added debugging code like the example below don't end up in the main JSBSim branch.

cout << "FGInputSocket::Read - Sim Frame - " << this->FDMExec->GetFrame() << " Data: " << data << endl;