Skip to content

Instantly share code, notes, and snippets.

@secondsun

secondsun/SyncRoadmap.md

Last active August 29, 2015 13:55
Show Gist options
  • Save secondsun/8695030 to your computer and use it in GitHub Desktop.
Save secondsun/8695030 to your computer and use it in GitHub Desktop.
Download ZIP
Raw
SyncRoadmap.md

M1 - Basic revision Control, Data Model, Change Management, Server <->

Client Contract

  • We seem to be in agreement on a basic set of metadata to be kept for each object. [objectId, revision, object].
  • We should have a basic server definition which supports CRUD and keeps our revision numbers in check. This may not be a server product but just a spec that can be implemented by anything at this point.
  • We should have basic client code which keeps up with revisions, can check the server for new revisions, and alert the user if there is a sync conflict.

M2 - Sync Listener w/ Polling based sync listener, conflict management,

  • We define on the client how callbacks will work for alerts when remote data changes
  • We implement a listener which polls a data source and delivers changes to the user.
  • We define how conflicts are managed

M3 - Push based Sync Listener, Sync Listener Strategy Management

  • The client and server will negotiate when it is appropriate to switch between polling, push, and realtime sync strategies.
  • We will build on our previous Listener work from M2 to include a Push listener that the server can speak to.
  • We will support ways of automagically managing sync listeners based on the availability of Push.

M4 - Server user management, Network Management, Server side session management

  • We will define in the client how network state and sync state interact. IE how to handle errors in fetching new data when the Listener is alerted. (Exponential back off, retry, etc)
  • The server will need to have some mechanism for managing user "sessions". This is what users are actively being synced.
  • The server should have a basic authentication and authorization plan for controlling how data is synced

M5 - "Real Time" Sync Listener. Bidirectional automatic sync

  • Instead of using push, Realtime Sync uses something like web sockects. to automatically sync local and remote data.
  • Previous Sync listeners may have to be upgraded to include "upload" abilities.
  • We will also include the ability to switch between Realtime sync listeners, polling listeners, and push listeners
  • The server will need to support this as well.

M6 - Conflict resolution, Error detection and support

  • Provide a more comprehensive strategy for managing conflicts.
  • Provide some automated conflict resolvers
  • The server could get a larger set of conflict and errors messages

M8 - Party

  • We have a sync party.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment