This would be wonderful. It would make the CSC more reliable, since it would not have to guess.
In my experience there are two basic ways to handle this:
1) Asynchronous commands:
Slow commands, such as point to point moves, are not done until the move finishes, fails, or is aborted. In this model you need to support multiple commands running at the same time (e.g. so a user can stop a point-to-point move) and commands need a client-assigned identifier, such as an integer sequence number (private_seqNum in SAL) that is echoed in command status replies. I suggest the following command status replies:
- started: the command has been accepted and started, but will take awhile to finish. Please include a predicted duration, preferably as a float/double in seconds.
- rejected: the command was unacceptable for some reason. Please include a string explaining the reason.
- succeeded: the command finished successfully.
- failed: the command failed after being acknowledged as started. Please include a string explaining why it failed.
- superseded: the command was superseded by another command. An example is starting a point-to-point move and then aborting it with a stop command.
This matches SAL pretty closely, but has no ACK, since I don't think we need it here. Any command should quickly receive one of these status replies.
2) Synchronous commands:
Make all commands run quickly, and only allow one command to run at a time.
In that model, slow commands such as point-to-point moves are reported as done when the command starts, and the client has to use other information to figure out when such commands finish. If you do that then I think you do not need the client to specify a command sequence number and you only need "succeeded", "failed" replies.
Story
This would be wonderful. It would make the CSC more reliable, since it would not have to guess.
In my experience there are two basic ways to handle this:
1) Asynchronous commands:
Slow commands, such as point to point moves, are not done until the move finishes, fails, or is aborted. In this model you need to support multiple commands running at the same time (e.g. so a user can stop a point-to-point move) and commands need a client-assigned identifier, such as an integer sequence number (private_seqNum in SAL) that is echoed in command status replies. I suggest the following command status replies:
This matches SAL pretty closely, but has no ACK, since I don't think we need it here. Any command should quickly receive one of these status replies.
2) Synchronous commands:
Make all commands run quickly, and only allow one command to run at a time.
In that model, slow commands such as point-to-point moves are reported as done when the command starts, and the client has to use other information to figure out when such commands finish. If you do that then I think you do not need the client to specify a command sequence number and you only need "succeeded", "failed" replies.