1123530 - [breakdown] Backend engine for syncing Reading List on desktop

Status: RESOLVED FIXED

(Firefox Graveyard :: Reading List, defect)

Description

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Desktop version of bug 1117830. We need a component to handle syncing data with the service being built at https://github.com/mozilla-services/readinglist/.

This can't be shared with Android (or iOS), as it'll be implemented as a native service there, and using native storage options.

Comment 1

[Richard Newman [:rnewman]]

I'm very happy to offer advice on this, when the time comes.

Myself and cloud services are still at the point of hammering out the spec and server, after which I'll be building out the Android client, then ultimately iOS.

Comment 2

[Mark Hammond (PTO; back Oct-3) [:markh] [:mhammond]]

I see 5 tasks here.  I'm going to summarize them here to gather some feedback before opening bugs:

* An "engine" with the logic for ensuring data is consistent between our local storage and the server API.  This is easy to picture at a high-level, but difficult at the low-level until we have the storage and server APIs defined.  The actual reconciliation logic should be relatively simple (although doing it efficiently with many thousand RL items will likely be a challenge.)

* A "scheduler".  This is the code that performs both scheduled and on-demand syncs (ie, we will schedule syncs, but also be able to respond to a notification of an entry being changed locally and thus sync out-of-schedule). This component will also be responsible for managing server backoff requests, sanely handling error conditions and online/offline state.  While this is similar to Sync's scheduler, that code is probably too specific to Sync for us to reuse it.

* Diagnostics, troubleshooting and support.  In particular, this will ensure the appropriate logs are collected and made available.  I propose we do this by reusing Sync's logging infrastructure.  We'd reuse about:sync-log for displaying these logs (but probably with a service-specific prefix on the filenames.)

* Surfacing error states.  Some browser-specific code to surface any necessary error conditions. We'd need to ensure the existing Sync-specific UI code interacts well with this - we don't want Sync *and* reading list to both show the exact same underlying issue (eg, auth attention required, we are offline, etc)

* FxA Authentication flows, particularly the integration with Sync.  This will mean we still use about:accounts for the login flow, but decouple that from being Sync specific.  This also implies a single, global authentication state shared between Sync and this service (eg, the "you must reauthenticate" state needs to be communicated in a way that it's not Sync specific, and both Sync and reading-list must react as this state changes.)  There are quite a number of UX related questions here, so my gut feeling is that this bug should itself be a breakdown.

Anything I'm missing, or anything that sounds plain wrong?

Comment 3

[Mark Hammond (PTO; back Oct-3) [:markh] [:mhammond]]

I opened bug 1131416, bug 1131412, bug 1131410, bug 1131413, bug 1131409, bug 1131414 and bug 1131415.  Marco, can you please add these to the iteration spreadsheet?

Comment 4

[Blair McBride [:Unfocused] (UNAVAILABLE)]

(Adding these as dependents, as it helps me track what's related to what)

Comment 5

[Marco Mucci [:MarcoM]]

(In reply to Mark Hammond [:markh] from comment #3)
> I opened bug 1131416, bug 1131412, bug 1131410, bug 1131413, bug 1131409,
> bug 1131414 and bug 1131415.  Marco, can you please add these to the
> iteration spreadsheet?

Thanks Mark.  I've added the bugs.

Comment 6

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Mass change of ReadingList bugs, moving to their own component. Filter bugspam on the following quote:

“Reading is to the mind what exercise is to the body.”
― Joseph Addison