Closed Bug 761682 Opened 12 years ago Closed 12 years ago

Version and reorganize prefs

Categories

(Firefox for Android Graveyard :: Android Sync, defect, P1)

ARM
Android
defect

Tracking

(Not tracked)

RESOLVED FIXED
mozilla17

People

(Reporter: rnewman, Assigned: nalexander)

References

Details

(Whiteboard: [qa+])

I'd like to see Sync's prefs arranged differently. $prefix.$account.$product.$profile.$pref.$version or $prefix.$version.$account.$product.$profile.$pref.$version For example: sync.alskdjalskjdalskjdalksjd.org.mozilla.fennec_rnewman.asdlkj123.default.next_sync.1 using whatever separators are convenient. Why? * Versioning is important for anything that persists longer than one run of an app. When we alter the granularity of a value, protocol versions, etc., we should not be limited to heuristics over the contents of a pref. Where we put the version controls how easily it is to blow away all old versions at once, versus relying on migration to clean up, but no big deal. Migration can run in our upgrade handler, or at lookup time. * A hierarchy on account, product, profile allows us to selectively address trees, just as we do in desktop, but in a manner that makes sense for us. We might wipe a whole account, an account for a particular product, or an account for a profile for a particular product. And we can actually store prefs that apply just to each layer in the hierarchy (for example, server backoff times apply to a server (for which the account is a reasonable approximation) and can thus be shared). Note that when we sync we know the product that's syncing, the profile (which I think we tie to the account right now, or assume is "default"), and the account hash, so we can trivially construct this tree. The existing prefs branch code can be bent to this end. See also Bug 714657.
Gonna be needed for multi-version support.
Priority: P2 → P1
So that we don't forget: our client record data and timestamps are attached to the Android Account object. That will likely need to be changed as part of this ticket.
So that we don't forget: our clients_database and history_extension_database are per APK and stored in /data/data/org.mozilla.fennec_ncalexan/databases/ as opposed to /data/data/org.mozilla.fennec_ncalexan/files/mozilla/$PROFILE/ These will probably need to be made per-profile in some undetermined way.
Possible collision dependency on Bug 772553. Being reviewed: https://github.com/mozilla-services/android-sync/pull/229
Assignee: nobody → nalexander
Status: NEW → ASSIGNED
Definitely want QA on this. (Will land when Inbound opens.) When this hits Nightly, please upgrade an existing Nightly account, and verify that Sync still works. Verify that repeated syncs work, with no log exceptions. If you're able to verify robustness with a flaky network, that would be awesome.
Whiteboard: [qa+]
Target Milestone: --- → mozilla17
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Product: Mozilla Services → Android Background Services
Product: Android Background Services → Firefox for Android
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.