Confirmed users
188
edits
Services/Sync/WEP/108: Difference between revisions
no edit summary
(WEP 108 first draft) |
No edit summary |
||
| Line 1: | Line 1: | ||
{{draft}} | {{draft}} | ||
== WEP 108 - Preference Sync == | == WEP 108 - Preference Sync == | ||
* Champions: Anant Narayanan | *Champions: Anant Narayanan <anant at mozilla dot com> | ||
* Status: Draft | *Status: Draft | ||
* Created: 05 Sep 2009 | *Created: 05 Sep 2009 | ||
* Reference Implementation: None | *Reference Implementation: None | ||
* [[Labs/Weave/WEPs|WEP Index]] | *[[Labs/Weave/WEPs|WEP Index]] | ||
=== Introduction === | === Introduction === | ||
We already support synchronization of Firefox preferences, but all preferences are synchronized as a single WBO with a fixed GUID. This method doesn't achieve expected results because whenever there is a conflict between even a single local preference value and a remote value, all synchronized preferences are replaced by the current local values (as per the default sync engine's "client wins" conflict resolution policy). | We already support synchronization of Firefox preferences, but all preferences are synchronized as a single WBO with a fixed GUID. This method doesn't achieve expected results because whenever there is a conflict between even a single local preference value and a remote value, all synchronized preferences are replaced by the current local values (as per the default sync engine's "client wins" conflict resolution policy). | ||
=== Scope for Improvement === | === Scope for Improvement === | ||
==== Split preferences into groups of WBOs ==== | ==== Split preferences into groups of WBOs ==== | ||
We don't store each preference as a single WBO because of the size and performance overhead involved. However, in order to reduce the chances that a conflict will result in a large number of preferences being set to undesirable values, we may split preferences into groups of WBOs instead of storing them in one giant object. | |||
This may be achieved by using Firefox preference branches: all preferences with a given prefix will be stored in a single WBO. The GUID of the object will be equal to the base of the preference branch, i.e. the prefix. | |||
There can be two types of preferences under the <tt>extensions.weave.prefs.sync</tt> branch: boolean and string. | |||
Any boolean preference under that branch indicates that the entire branch is to be synchronized. For example, setting <tt>extensions.weave.prefs.sync.browser</tt> to <tt>true</tt> will result in one WBO with GUID <tt>browser</tt> containing all values under the browser.* preference branch. | |||
A string preference, on the other hand, indicates that only the specified (comma-separated) subset of values in that preference branch are to be synchronized. For example, setting <tt>extensions.weave.prefs.sync.browser</tt> to <tt>'download.manager.scanWhenDone,search.openintab,search.selectedEngine'</tt> will create a WBO with GUID browser containing only the preference values <tt>browser.download.manager.scanWhenDone</tt>, <tt>browser.search.openintab</tt>, and <tt>browser.search.selectedEngine</tt>. | |||
This problem is especially noticeable while using Personas, as the "default" (currently, Groovy Blue!) persona is selected on all clients whenever a new client is added to a user's account. | ==== Intelligently detect default values ==== | ||
Consider the case of somebody setting up Weave for the first time on a new computer with an existing account. As all preferences have default values at this stage, the sync engine detects a conflict and applies local values to the single WBO which then propagates to all other clients. | |||
This problem is especially noticeable while using Personas, as the "default" (currently, Groovy Blue!) persona is selected on all clients whenever a new client is added to a user's account. | |||
This problem is harder to solve because we can never know if the default value is what the user wants / is the latest correct value. One approach is to assume that if the remote WBO contains a non-default value for a preference, but the local value is equal to the default, we apply the remote value locally all the time. | This problem is harder to solve because we can never know if the default value is what the user wants / is the latest correct value. One approach is to assume that if the remote WBO contains a non-default value for a preference, but the local value is equal to the default, we apply the remote value locally all the time. | ||