Page MenuHomePhabricator

Implement SyncAdapter for Reading lists (nee: Collections)
Closed, DuplicatePublic

Description

After the initial groundwork on the userjs SyncAdapter, it should be straightforward to duplicate the sync functionality to apply to collections Reading lists, as retrieved using the Gather API.

Event Timeline

Change 346804 had a related patch set uploaded (by Dbrant):
[apps/android/wikipedia@master] [PoC] Synchronize reading lists to user's account.

https://gerrit.wikimedia.org/r/346804

RHo renamed this task from Implement SyncAdapter for collections to Implement SyncAdapter for Reading lists (nee: Collections).Apr 10 2017, 4:19 PM
RHo updated the task description. (Show Details)

Change 346804 abandoned by Dbrant:
[PoC] Synchronize reading lists to user's account.

https://gerrit.wikimedia.org/r/346804

Change 347604 had a related patch set uploaded (by Dbrant):
[apps/android/wikipedia@master] Synchronize reading lists to user's account.

https://gerrit.wikimedia.org/r/347604

I'm about to dig into the code for the current proposed implementation but I want to be sure we're thinking a few things through adequately now because it may be difficult to change the later (i.e., when the real syncing backend is in place). I don't want to hold things up, but also don't want to make any hasty, ill-considered decisions we'll regret later.

1) Do we want to commit to passing around full lists?

AIUI the current implementation is based on passing around entire reading lists. This is simple but inefficient. Is this the model we want to commit to forever? One promising syncing implementation I've seen described involves sending timestamped create/update/delete/whatever events to the server, then having clients retrieve only new events at the start of a session and reconcile them. Would this be that much harder to implement? (OK, it probably would be awkward at the very least while we're backed by userjs as opposed to a real database.)

2) How will we manage the transition to the new backend, esp. if it expects something other than full lists?

What if we want to change the implementation to something more efficient later? What if the architect(s) of the real syncing backend aren't OK with passing full lists around? Users who never upgrade from a version that uses userjs to sync lists should be fine forever but I'm pretty concerned about how we'll manage the transition in the event the syncing content format changes.

(Edit: Previously considered content format versioning, but that won't be helpful for the transition if the move is to a completely different API, unless we provide for old-style syncing for existing users in the new backend.)

Change 347604 merged by jenkins-bot:
[apps/android/wikipedia@master] Synchronize reading lists to user's account.

https://gerrit.wikimedia.org/r/347604