This is a smaller version of the scores_sync PR #257.
It doesn't contain the code cleaning done in the other PR. Instead, it only contains the code required to achieve the seamless sync of the scores.
Problem: the user need to click buttons for the scores to synchronize between him and the other clients.
Complications: the client must be able to work alone in case the server fails.
Solution: Adding a special service to the client, that is responsible for it's independence (And therefore it's called ng-independence). Upon using it, it will try sending a request to a specified URL, and if it failed, it will keep the request in the browser's local storage, and run a previously specified fallback function. When a request is successful, it will send all saved requests.
The ng-scores then uses this service to make requests to the server, so it will keep it's independence.
In order to create a full sync between the scoresheets and the scores.json, whenever a scoresheet is entered, so does the score entry in the scores.json, and the scoresheets are polled upon server start. That means the scores.json will always be in sync with the scoresheets, even if the server fails mid-process.
And last, for all of this to become possible, and to out rule problems such as information overriding and deadlocks, we use a CRUD API in the server, instead of a stupid server, so that we have one authority to manage the changes to scores.json.
This is a smaller version of the scores_sync PR #257. It doesn't contain the code cleaning done in the other PR. Instead, it only contains the code required to achieve the seamless sync of the scores.
Problem: the user need to click buttons for the scores to synchronize between him and the other clients. Complications: the client must be able to work alone in case the server fails. Solution: Adding a special service to the client, that is responsible for it's independence (And therefore it's called ng-independence). Upon using it, it will try sending a request to a specified URL, and if it failed, it will keep the request in the browser's local storage, and run a previously specified fallback function. When a request is successful, it will send all saved requests. The ng-scores then uses this service to make requests to the server, so it will keep it's independence.
In order to create a full sync between the scoresheets and the scores.json, whenever a scoresheet is entered, so does the score entry in the scores.json, and the scoresheets are polled upon server start. That means the scores.json will always be in sync with the scoresheets, even if the server fails mid-process.
And last, for all of this to become possible, and to out rule problems such as information overriding and deadlocks, we use a CRUD API in the server, instead of a stupid server, so that we have one authority to manage the changes to scores.json.