Services/Sync/WEP/105

From MozillaWiki
< Services‎ | Sync‎ | WEP
Jump to: navigation, search
Draft-template-image.png THIS PAGE IS A WORKING DRAFT Pencil-emoji U270F-gray.png
The page may be difficult to navigate, and some information on its subject might be incomplete and/or evolving rapidly.
If you have any questions or ideas, please add them as a new topic on the discussion page.

WEP 105 - Record Importance Definition

  • Champions: Mike Connor
  • Status: Draft
  • Type: ?
  • Created: 2009 Aug 12
  • Reference Implementation: TBD
  • WEP Index

Introduction and Rationale

Weave needs to sync data to disparate clients with widely varying resource constraints and use-cases. Not all data is created equal, and especially in mobile (and possibly netbook) cases we want to only retrieve the most important data. However, on desktop systems, we want to sync all user data in order to make the user experience truly the same everywhere. When two desktops are fully synced, the user should have the same user experience on both machines.

By creating a simple importance metric we can create an effective and useful subset for resource-constrained clients without having to limit sync for the desktop cases.

Proposal

Create a straightforward importance value for each record (descriptions are based on how often the record would be used/useful to the user, possible examples in parens)

  1. Always (tabs, passwords, top 100 Places)
  2. Usually (top 200 form history entries, preferences, top 500 Places)
  3. Often (top 500 form history, top 2000 Places)
  4. Sometimes (top 1000 form history, top 5000 places)
  5. Rarely (all remaining data)

Mobile clients could sync 1/2 or 1/2/3 depending on resources/performance tradeoff, desktop clients would sync all data based on whatever algorithm is deemed most effective.

Pre-Requirements

TBD.

New Opportunities

  • Remove limits on what is synced by desktop clients
  • Provide a clean way for limited-resource clients to pull a subset of server data

Other Proposals

  • There's been talk of an unbounded/unspecified "interestingness" value for records. Not sure on the details, or how this would work for limited-resource clients.