Design syncing protocol that is platform agnostic.
Syncing protocol should consider:
Compression
Prioritize transfer items - on limited connections (like QR codes), give the user control over only syncing top priority items.
Merge conflicts - how to avoid them, or at least handle them if they occur. Merge strategies (smart, manual resolution, ranked off scouter, etc.)
Leveraging the advantages of each sync method. For example, devices may form a Bluetooth mesh network and discover an online node and will route all traffic through the higher speed internet on this node to reach the master device faster.
Syncing must also consider what to sync:
Assignments
Picks
TBA data (proxy)
Scouting data (and content files)
Events and the matches, teams within them
For maximum flexibility, all events should be synced all the time (remove the restriction of one active event). A team may archive an event to stop it from syncing, but it will naturally stop syncing if data is stopped being added to it. This would allow more use cases for teams who'd like to create multiple "Roblu event" objects for an event to separate out data. Maybe they contribute to another event for another team as well.
Further along, we might want to model "syncs" as "pull requests" that can have permissions (needs approval, anyone can merge, etc.). Especially if we want to support public events that anyone can make a "pull request" to.
Additionally, a better improvement to sync over legacy would be to NOT perform merging during the transfer, but to instead ONLY transfer data, close the connection & report sync as success, then merge at the receiver's leisure.
Design syncing protocol that is platform agnostic.
Syncing protocol should consider:
Syncing must also consider what to sync:
For maximum flexibility, all events should be synced all the time (remove the restriction of one active event). A team may archive an event to stop it from syncing, but it will naturally stop syncing if data is stopped being added to it. This would allow more use cases for teams who'd like to create multiple "Roblu event" objects for an event to separate out data. Maybe they contribute to another event for another team as well.
Further along, we might want to model "syncs" as "pull requests" that can have permissions (needs approval, anyone can merge, etc.). Especially if we want to support public events that anyone can make a "pull request" to.
Additionally, a better improvement to sync over legacy would be to NOT perform merging during the transfer, but to instead ONLY transfer data, close the connection & report sync as success, then merge at the receiver's leisure.