Closed
Bug 761682
Opened 12 years ago
Closed 12 years ago
Version and reorganize prefs
Categories
(Firefox for Android Graveyard :: Android Sync, defect, P1)
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.
Assignee | ||
Updated•12 years ago
|
Priority: -- → P2
Assignee | ||
Comment 2•12 years ago
|
||
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.
Assignee | ||
Comment 3•12 years ago
|
||
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.
Reporter | ||
Comment 4•12 years ago
|
||
Possible collision dependency on Bug 772553.
Being reviewed:
https://github.com/mozilla-services/android-sync/pull/229
Assignee: nobody → nalexander
Status: NEW → ASSIGNED
Reporter | ||
Comment 5•12 years ago
|
||
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+]
Reporter | ||
Comment 6•12 years ago
|
||
Reporter | ||
Updated•12 years ago
|
Target Milestone: --- → mozilla17
Comment 7•12 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Updated•12 years ago
|
Product: Mozilla Services → Android Background Services
Updated•7 years ago
|
Product: Android Background Services → Firefox for Android
Updated•4 years ago
|
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•