cloudkucooland
commented
3 years ago https://github.com/wasabee-project/Wasabee-Server/commit/bf73278ce4cd49555562a7789cef41b2f4de8b7b
Associated server change.
Closed cloudkucooland closed 3 years ago
cloudkucooland
commented
3 years ago https://github.com/wasabee-project/Wasabee-Server/commit/bf73278ce4cd49555562a7789cef41b2f4de8b7b
Associated server change.
cloudkucooland
commented
3 years ago https://github.com/wasabee-project/Wasabee-Server/commit/bf73278ce4cd49555562a7789cef41b2f4de8b7b
Associated server change.
le-jeu
commented
3 years ago why not leave this intelligence to the server, if the assignment/state change, then do firebase things ?
cloudkucooland
commented
3 years ago why not leave this intelligence to the server, if the assignment/state change, then do firebase things ?
That would require checking each and every marker/link state on each and every upload, with all the performance implications of that added workload.
I'll build a test and see how much impact such a method would have.
cloudkucooland
commented
3 years ago Marked as draft until I can properly test the performance of doing all the work in the server.
Problem:
Firebase messages for link/marker assignments not sent when using the normal update method, only when using the atomic API calls. This limits the potential of the mobile client from displaying important information to the agents real-time.
Proposed solution:
Add a "changed" flags to markers and links in the op JSON. Wasabee-IITC will set this flag when a state change that needs a FB announcement is sent. Server will look for these flags and send announcements if appropriate.