This implements a new improved version of the server protocol. The following changes have been made:
The protocol is based on JSON messages. This allows for example for more structured commands where it's easier to provide multiple arguments for a command and even have optional arguments.
For each command, there is a corresponding response. It is either a success response with possibly the value that you requested, or an error response with an error code.
On top of the responses you also get sent event messages that indicate changes to the timer. These can either be changes triggered via a command that you sent or by changes that happened through other sources, such as the user directly interacting with the timer or an auto splitter.
The protocol is still work in progress and we will evolve it into a protocol that fully allows synchronizing timers over the network. #260
The event sink has now been renamed to command sink, because there is now a clear distinction between incoming commands and events that are the results of these commands.
Oh and because we now have specific error conditions for all the commands (split, undo_split, ...), there's a test for every possible error condition on every command. I think that should really help with robustness.
This implements a new improved version of the server protocol. The following changes have been made:
success
response with possibly the value that you requested, or anerror
response with an errorcode
.event
messages that indicate changes to the timer. These can either be changes triggered via a command that you sent or by changes that happened through other sources, such as the user directly interacting with the timer or an auto splitter.The protocol is still work in progress and we will evolve it into a protocol that fully allows synchronizing timers over the network. #260
The event sink has now been renamed to command sink, because there is now a clear distinction between incoming commands and events that are the results of these commands.