Setting the sync token here marks the memory store part as being
synced up to that point, but it isn't because the sync data hasn't
yet been injected into it.
The sync token will be set in the normal way when the cached sync
response is processed, at which point it will be accurate because
the cached sync data will actually have been processed by the sync
code and saved to the memory store.
- failedSyncCount -> this._failedSyncCount
- Reset at a point which is more obviously after a successful sync, and add comments to clarify the recursive syncage.
- Sync state will now flip from RECONNECTING to ERROR after FAILED_SYNC_ERROR_THRESHOLD syncs
when a /sync leads to an error, increase a counter and use the counter to decide which state to be in when starting keepAlives. If the count is above a certain threshold (arbitrary 3 chosen here), switch from RECONNECTING to ERROR to show that the server is facing difficulties that aren't affeting is ability to return on /versions.
* Make sync communicate with the sync accumulator via the store
* Consequently get rid of getSyncAccumulator as it's now
unnecessary.
* Make the bit that gets the saved sync response async, because
we'll need it to be when it's coming over postMessage from a
webworker.
Hide the IndexedDBBackend and SyncAccumulator objects and have
indexeddbstore instaniate them itself, rather than making the app
instantiate them. Pass the approipriate options through. This
gives us much more flexibility to move things around under the
hood.
Syncing should probably mean the stream is up to date and
streaming messages in real-time from the server, which is not the
case if we've only loaded the cached response. Stay PREPARED until
we actually get the latest from the server.
video.src = URL.createObjectURL(stream) is on the way out. Firefox will
complain with errors about not being able to play media of type
"text/html" for example.
David Baker